alt Hacker NewsAs someone who has had to deal with OAuth quite a bit at work, I like it for the most part, but it's just so dang big and complicated.
Almost everyone thinks of OAuth as the "three legged redirect" flow, where one site sends you to another, you say "Yes, I authorize" and it sends you back, and now that site can act as you on that other site.
But that's just the tip of the iceberg! That's called the "authorization code" grant, because implementation wise the one site gives a special one time authorization code to the other one, which it can then exchange server-to-server to get the actual sensitive access credential.
What about if the human isn't in the loop at that moment? Well you have the "client credentials" grant. Or what if it's limited input like a TV or something, well then you have the "device" grant.
And what if the client can't securely store a client secret, because it's a single page web app or a mobile application? Then it has to be a public client, and you can use PKCE or PAR for flow integrity.
What if you can't establish the clients up front? There's DCR, which is all important now with MCP. But then that either lets unauthenticated requests in to create resources in your data stores, or needs to be bootstrapped by some other form of authentication.
It's all just a sprawling behemoth of a framework, because it tries to do everything.
Replies
>It's all just a sprawling behemoth of a framework, because it tries to do everything.
it is, but at the same time, that's kind of great. it handles all the things. but you don't have to use them all. for me, the point of oauth is that there's this whole complicated mess of stuff that happens in the auth layer, but the end result is a bearer token and maybe a refresh token.
you can build that mess of auth yourself, or you can swap in any of a bunch of different third-party providers to do it for you, because they all just give you the same bearer and refresh token. then you can build your app in a way that doesn't care about auth, because it all gets handled inside that oauth box. are you currently serving a request that came from a client credentials grant, or an authorization code grant? was it a pkce client? it doesn't matter outside the client.
> It's all just a sprawling behemoth of a framework, because it tries to do everything.
Yeah, I mean it can be, but it doesn't have to be, depends entirely on what you need. And if you need those things, like machine-to-machine authentication, where you can't establish clients up front, you need to do something about it anyways, why not just go with something others might already know?
> It's all just a sprawling behemoth of a framework, because it tries to do everything.
I also interact with OAuth quite a bit at work. I also have dealt with SAML.
I'd pick OAuth over SAML any day of the week, and not just because OAuth (v2 at least) is 7 years younger.
It's also because OAuth, for all its sprawl, lets you pick and choose different pieces to focus on, and has evolved over time. The overall framework tries to meet everyone's needs, but accomplishes this via different specs/RFCs.
SAML, on the other hand, is an 800 page behemoth spec frozen in time. It tried to be everything to everyone using the tools available at the time (XML, for one). Even though the spec isn't evolving (and the WG is shut down) it's never going to go away--it's too embedded as a solution for so many existing systems.
I also don't know what could replace OAuth. I looked at GNAP but haven't seen anything else comparable to OAuth.