On Fri, Aug 19, 2022 at 3:06 AM Stuart Henderson via mailop < [email protected]> wrote:
> On 2022/08/19 09:08, Gellner, Oliver via mailop wrote: > > Hello, > > IMAP, SMTP etc are still being supported with Office365. What gets > > disabled is Basic Auth for some services. Microsoft announced the > > decomission of Basic Authentication three years ago and all tenant > > administrators have been notified several times in the meantime about > > this change. Originally the change was planned for 2020, but due to > > interoperability issues it got postponed until 2022. So while I'm no > > Microsoft fellow I don't think anyone should be caught unprepared. > > The interoperability issues have not been fixed though. > > > If you need POP3 or IMAP4 access with Basic Auth, then you can either > > put a proxy or other email server in between which speaks Basic Auth > > on one side and OAuth on the other. > > That proxy will have the same issue as seen by other tools accessing the > OAuth2-only services. Hideously complicated configuration, having to keep > tokens refreshed, etc. > > It would seem sensible for operators who want to require something > stronger than basic authentication to have a way to use TLS with client > certificates as an alternative to OAuth2, it would be a lot more > straightforward to handle on the client side. Unless they have other > motives. It's not really surprising to see this exact thing mentioned > on https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish Who thinks managing and refreshing client TLS certificates is easier than OAUTH2? I know here at Google we use them extensively with our beyondcorp system for browser access to internal tools, and I don't know the amount of effort the corp IT folks have put into making it work, but it's far from trivial on the user side. Given that Google is in the same position in regards to preferring OAUTH over username/password, I understand the pain from both sides which is being captured here... but I don't think TLS would solve the same problems... perhaps purely in the enterprise space it could work, which I guess is the focus here. Ie, we use it at Google for multiple improvements: - Stop using just passwords and support other auth mechanisms including 2FA - Force the user to the browser or OS components for login which are standardized and have much stronger login controls and protections due to the resources put into this flow. We've had anti-abuse and anti-hijacking teams working on these flows for a very long time at this point. They will then be able to take advantage of improvements to those without having to update the individual application... for instance, the most popular user operating systems are all moving to supporting FIDO2 and WebAuthN directly. - Better and more controlled error messaging including in multiple languages... as stated in the original message, many clients have poor to non-existent support for login failures, many treating any failure as wrong password. - Tie a particular authorization to a particular set of abilities. This means that if the tokens are stolen, the data that's available is limited. The user is also able to judge whether a particular ask for access is what they want. That said, email is often the keys to the rest of the kingdom, so the access level is really high anyways... and users will give away just about anything even if asked. - Tie a particular authorization to a particular application. There has been a lot of abuse by third parties with access to user data, and the holders of that data have been held responsible in the court of public opinion and sometimes in actual court for that, especially as laws like the GDPR propagate. 0365 and Workspace both allow access to applications on an admin whitelist basis, which is certainly easier than the certification process that is required for consumers. - Tie a particular authorization to a particular device... this one is not strongly done, but the mechanism means in practice that separate devices are authorized separately. This helps with some antiabuse investigations and enforcement, especially as users travel. - Time limit a particular authorization. By requiring refreshes at intervals, re-evaluation of the authorization can be done. I won't say that OAUTH is the perfect solution to all of these issues, but it is definitely an improvement for them. Could TLS client certs have been issued in place of the tokens in these schemes? Maybe? Not sure what it would have gained, though. Maybe it would have been based on mTLS if that had been available earlier. And yes, the fact that the OAUTH discovery and registration standardization came much later, and the fact that due to the newer requirement for application certification that hasn't become something that is well supported is unfortunate for these cases. As for the embrace and extend argument, OAUTHBEARER used here is an RFC from 2015, and OAUTH2 it's based on is from an RFC from 2012. These standards were all created in the open and have been available for a long time. Brandon
_______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
