💾 Archived View for tilde.pink › ~bencollver › why-oauth2-stinks.gmi captured on 2022-07-16 at 13:49:54. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-06-03)
-=-=-=-=-=-=-
According to the old joke, a camel is just a horse that was designed by a committee: when it came to OAUTH2, though, what the committee produced was more like a two-wheeled donkey.
OAUTH2 is a suite of documents that defines an authentication and authorization process--a set of rules and procedures that allows a user to control how a program can login to a service (for instance, to send mail), and what it can do while it is logged in. Many of its goals are entirely admirable:
There are other more minor benefits that the developers of the framework make reference to, but these are the main ones the user will see. But you only get benefits from something like this if it is well-designed and implemented.
Very annoyingly, sites like GMail and Microsoft's outlook.com site have taken to calling OAUTH2 "modern authentication", as if this somehow marks it as a well-thought-out, balanced mechanism: unfortunately, neither is true.
OAUTH2 has had a very checkered history: originally a rather more complex framework called OAUTH 1, the process of developing OAUTH2 was so internally fraught that the lead author of the specification resigned and removed his name from the process before it was released. If you'd like to see a little history of OAUTH2, Wikipedia has an article here:
So why am I so critical of OAUTH2? Let me count the ways...
Before I start, though, I have to be clear up front about one thing: many of the goals of OAUTH2 are valid and worthwhile: my problems with it are exclusively to do with how it has been implemented. In my nearly thirty-five years of writing software in service of the Internet, OAUTH2 is the worst-conceived piece of software design I have ever encountered. More troublingly, it shows the increasing levels of control and power exercised by large, usually American corporations over the Internet, and the almost complete disregard they have for its historical openness and inclusiveness. OAUTH2 is a major step on the way to an Internet where the only players are large corporations, serving their own interests in the name of profit and power.
The main problem with OAUTH2 can be seen in the first paragraph of the 'standard' that defines it--RFC6749:
The OAuth 2.0 authorization framework...
--in other words, OAUTH2 is not a standard--it is instead a broad guide to how something claiming to be an "OAUTH2 implementation" should behave. Earlier protocols such as POP3, SMTP and IMAP, while undoubtedly flawed in the area of authentication, at least specified the detail of how the protocols worked: the OAUTH2 specification does not do this--rather, it defines broadly how an OAUTH2 implementation might work. It lays down little in the way of actual rules, and does not mandate any particular implementational detail. This leads me to my largest criticism of OAUTH2:
The next issue is in some ways even worse: client developers, such as myself, are required to register their program with every OAUTH2 provider they wish to support. Once again, this can easily be viewed as a cynical power-grab: small-to-medium developers simply do not have the resources to be able to manage hundreds or even thousands of separate registrations in this way. At best, we will be limited to supporting a handful of the largest providers--which a sceptic like myself can easily construe as being just what those providers want.
But there's an even darker aspect to this requirement that is perhaps not immediately apparent: what happens if a site declines to accept your registration, or revokes your registration at a later time? Suddenly, a corporation (because the large players are all corporations) has control over whether or not your program is useful to your users: in other words, after thirty-five years of providing Pegasus Mail as a service to the broader Internet, I now find myself in a place where its usefulness and applicability is becoming subject to the whims of large, unaccountable corporations. To summarize my second main objection to OAUTH2, then:
Those two points would, on their own, have been enough to explain my antipathy for OAUTH2, but wait--there's more! OAUTH2 is needlessly complex: using my experience as an example, developing an even marginally useful OAUTH2 client for Pegasus Mail has required that I understand several Internet Standards Documents (or RFCs in industry parlance) that are severely jargon-ridden even according to the norms of such documents; because OAUTH2 appears to have been concocted almost entirely by web developers, it has also required me to write nearly 7,000 lines of code, just to support GMail:
... and so it goes on. I estimate it has taken me more than 200 hours to get to the point of having something that works with a single provider--200 stressful, frustrating hours for which nobody has paid me anything, and which have kept me away from other tasks that I consider a lot more important.
Things have not been helped by GMail: while it is not my intention to suggest that GMail is any worse than any other implementor, it is the one with which I am currently familiar, and hence the only one whose issues I feel competent to describe:
- You have provided an expired token--refresh it and try again.
- The syntax of your command is incorrect
- The syntax of the token block you provided is incorrect
Finally, it's worth mentioning GMail's "improved user experience", which involves the user going through a quite scary sequence of dialogs that warn of the application deleting all their mail and insist that the user know and trust the program, all the while offering no fewer than three places where they encourage the user to back away... Look, it's fine to warn the user, but the GMail "user experience" looks more like one designed to frighten the average casual user away from allowing access to the application. More corporate heavy-handedness, anyone?
So now we have reached point three in my list of OAUTH2 donkeyisms:
Amazingly, there is more, but if you've read this far in this document, I admire your stamina, and won't burden you with more ranting.
At a personal level, as I remarked above, developing an OAUTH2 client for GMail has been a frustrating, stressful experience that I regard as a complete waste of time I could have spent on any number of other more deserving tasks.
But I'm afraid there's probably little that can be done about it now. The agenda is already written, and the corporate spin machine will probably not even regard this little litany of complaints as worth reading.
I just hope the Internet can cope with this perversion and move past it at some stage.
--David Harris
May 2nd 2022.
I have today attempted to submit my application, Pegasus Mail, to GMail to go through their "validation process". Clicking the button that said, simply enough, "Publish App" took me to a bewildering, convoluted multi-list screen of different terms, conditions and requirements--even including the demand that I make a Youtube video showing the code operating (seriously?!).
That, while burdensome, confusing and complicated would probably have been manageable--and of course, it's all freighted in terms of "protecting GMail users' data", so you cannot be seen to criticize it without appearing to be somehow irresponsible... But right at the end is the sucker punch--Google will charge you from "$10,000 to $75,000 or more" (their words, not mine) for this, and will require you to go through the process (and of course, pay the fee) annually.
I refer you back to my original contention that OAUTH2 is a step towards an Internet completely controlled by large corporations: perhaps you thought that statement was an exaggeration when you read it then--do you still think that now?