OAuth sucks. It's one of the worst abstractions of our time. It's incredibly easy to implement some half assed spaghetti and call it "standard OAuth".
When the environment involves delegating authentication across service providers, dealing with browsers and native clients, mobile apps, etc, there will not be a simple solution.
This is made even more challenging by constantly evolving application and edge deployment architectures, each bringing with it a new element of complexity.
OAuth sucks, and I’m sure it could be replaced with something better, but that replacement will also suck and bear a passing resemblance to OAuth, because the underlying problem is a messy one that isn’t going away soon.
It's by far not THE worst, you're spouting total nonsense. What's THE worst is lack of attention, and one needs quite literally 10 minutes to read the RFC and understand it's fairly simple protocol with minimal number of parameters.
I'm sorry you had a hard time with OAuth, but have you ever thought the problem is in you and not the protocol? Reason I'm asking is because you declare it sucks but you are not providing any kind of alternative of how it would not suck.
rfc 6749 is 4259 words according to wc -l. You mean that it takes 10 minutes to carelessly skim it.
Never mind that there are several other OAuth RFCs.
Most people I worked with don't understand the purpose of OAuth and that's what the 10 minutes should be invested into.
Or, you can, you know - nitpick and live in the world of gloom and doom where everything sucks.
What I learned after delivering the content to hundreds of devs over the years: OAuth confuses people, and for completely understandable reasons. Most people think about auth in terms of usernames/passwords or API keys. The mental models associated with these do not transfer to OAuth, and there are enough moving parts with client and server-side interactions that someone not already steeped in the authn/authz space will have some catching up to do.
Forming an understanding of the basic concepts rarely happens in 10 minutes, and if that’s your experience, good on you. Most of us bang our head against the wall for a bit and some of us go on to teach classes about it.
Bottom line: OAuth is hard. That is not the same thing as the general concept being simple.
OAuth is hard to explain here because it is not an authentication protocol, and without extensions has severe security flaws in being one. OpenID Connect is the most popular effort extending OAuth to also handle authentication.
But that doesn't change that the thing OAuth is most associated with is not what it actually sets out to accomplish.
I once worked with a vendor who provided an API and required all API clients to use OAuth with Auth Code Grant Flow. The API was designed to support backend automation use cases within the product, and could execute functionality behind the scenes headlessly. Auth Code Grant Flow requires interactive login by a user sitting at a keyboard, and they never stopped to consider that backend automation use cases are not going to work well if someone has to periodically execute an interactive auth flow. This wasn't a once-in-a-year occurrence since they enforced relatively short refresh token timeouts.
The degree of confusion and the prevalence of that confusion on this subject is quite high. Someone gets a task to "Implement OAuth", and they see that Auth Code Grant Flow is the most common, so that must be what we should implement.
It happens when you're working and have sufficient experience, knowledge and practice when it comes to web, programming and HTTP.
It's impractical, irresponsible and insane to have anyone other than a person with sufficient knowledge to work on application / API that supports OAuth and for person with proper expertise - the protocol is simple because it's literally the bare minimum needed to establish secure request/response pattern.
I work with SAML 2.0 and OAuth2/OIDC, I deal with programmers and other people within areas of API, authentication, authorization and it is true that majority of people I interacted with are having troubles understanding these protocols. However, what I can attest to is that they're also extremely underwhelming as people working in IT, with bad work habits and misplaced focus. It's impossible to explain or clear up the protocol to such audience because they lack much more when it comes to knowledge and discipline. But, I did interact with several brilliant people with far less experience compared to me who did get the purpose of this protocol and who implemented it successfully and have done so quite fast.
What the wall of text means is that where there's will - there's a way. You can't force knowledge into audience who can't or refuse to understand it, so there's no point in even trying to do it let alone draw conclusions how the protocol is hard, confusing or difficult when there's whole knowledge void in other pre-requisite areas.
In my experience, IT generalists are dealing with a thousand problems, and that has little to do with misplaced focus and more to do with the fact that management just spent $$$ on this new platform and needs it integrated with internal systems, and they're encountering this OAuth thing out of necessity.
Part of the reason my training materials were successful within that community was because they distilled all of the usual questions about how and why someone would use OAuth relative to the platform and presented essentially a menu of recommended options to be explored further depending on their use case.
And people found success with this approach because it helped them solve their very immediate and concrete problem while also explaining why the approach solves that problem.
> You can't force knowledge into audience who can't or refuse to understand it, so there's no point in even trying to do it let alone draw conclusions how the protocol is hard, confusing or difficult when there's whole knowledge void in other pre-requisite areas.
Different people have vastly different learning styles, and some people just don't do well if you hand them a dense specification. Working from concrete use cases can be far more productive since it meets users where they are and gives them a pathway to understanding how their use cases connects to the OAuth concepts.
In a perfect world, everyone who works on auth would be experts. In the world we have, quite a few people have no choice but to do their best to learn the subject matter to solve the problem at hand.
Unfortunately this also leads to quite a bit of confusion and some really problematic OAuth implementations.