What Is OAuth?
leaflet.pub
leaflet.pub
[1] "...Eran Hammer resigned from his role of lead author for the OAuth 2.0 project, withdrew from the IETF working group, and removed his name from the specification in July 2012. Hammer cited a conflict between web and enterprise cultures as his reason for leaving, noting that IETF is a community that is "all about enterprise use cases" and "not capable of simple". "What is now offered is a blueprint for an authorization protocol", he noted, "that is the enterprise way", providing a "whole new frontier to sell consulting services and integration solutions". In comparing OAuth 2.0 with OAuth 1.0, Hammer points out that it has become "more complex, less interoperable, less useful, more incomplete, and most importantly, less secure". He explains how architectural changes for 2.0 unbound tokens from clients, removed all signatures and cryptography at a protocol level and added expiring tokens (because tokens could not be revoked) while complicating the processing of authorization. Numerous items were left unspecified or unlimited in the specification because "as has been the nature of this working group, no issue is too small to get stuck on or leave open for each implementation to decide."
David Recordon later also removed his name from the specifications for unspecified reasons. Dick Hardt took over the editor role, and the framework was published in October 2012.
David Harris, author of the email client Pegasus Mail, has criticised OAuth 2.0 as "an absolute dog's breakfast", requiring developers to write custom modules specific to each service (Gmail, Microsoft Mail services, etc.), and to register specifically with them."
At the end of a talk about Oauth 2.0 at some indie or fediverse conference during lockdown, Aaron Parecki, who was then and still is employed at Okta, was asked if it might not be worth isolating the parts of the protocol/flow that actually requires a service (i.e. protocol-aware server in the loop) from those that don't, so that you could still get limited authentication/identity-tagging if your "provider" is your personal domain where you're just hosting static site. He immediately acted like he was addressing the dumbest person in the virtual room (it was a remote conference), telegraphing through his response that he might actually be on the verge of physical pain having to deal with such an imbecilic question.
I'm having a dense moment, so I can't quite grasp what the person asking wants to achieve, or what flow they envision. Can you help by spelling it out?
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.
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?
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.
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.
"At its core, OAuth for delegation is a standard way to do the following:
The first half exists to send, with consent, a multi-use secret to a known delegate.
The other half of OAuth details how the delegate can use that secret to make subsequent requests on behalf of the person that gave the consent"
This paragraph has a bunch of words that need defining (the word delegate does not appear on the page until then) and a confusing use of 'first half', 'second half' .... First half of what?
Surely it can be explained better than that?
Delegate is just a standard word, look it up on a dictionary. If anything its internal technical definition is precisely in that sentence.
>"First half of what"
The spec, the standard, half of it deals with X, the other half of it deals with Y. Namely one half being how user grants permission to a third party, and the other half being how the third party makes requests to the main data holder.
If you need another definition: OAuth is a three way protocol between users, a service provider, and a third party. A user gives specific permissions to the third party, so that the service provider can share specific resources with the third party, who acts on the user's behalf.
Thanks, it did not.
OAuth and OpenID Connect are a denial of service attack on the brains of the humans who have to work with them.
I do not understand what I am doing and trust the docs, but it has never been a particularly difficult setup.
I would argue that then you do not "have to work with them", you are merely using products built with them.
How can B be sure that C is acting on A's behalf? Can A only allow C to access certain data (or send only certain data) in order to reduce risk?
A protocol that allows for that three way negotiation is OAuth.
Like with most specs, a lot of the complexity is added in the later years, by companies that have thousands of users and complex edge cases and necessities, and they are the ones dominating the council, and their needs are the ones that push forward newer versions.
So with most specs, the best way to start learning it is by learning from the oldest specs to the newest ones, so if you start by reading or using OAuth2, you will be bombarded with a lot of extra complexities, not even the current experts started like that.
If you need to catch up, always start with the oldest specs/versions.
So thanks!
I'll start reading the oldest HTTP spec for funzies.
Fwiw it's entirely possible to build a web server by listening on port 80 and reading the text stream and writing to the output stream, no libraries no frameworks no apache no ngninx. And I don't mean you need to rebuild a general purpose an apache like server, maybe for a landing page you can just serve a static page and you will be implementing a very small subset of HTTP.
> Fwiw it's entirely possible to build a web server by listening on port 80 and reading the text stream and writing to the output stream
Sounds like a fun weekend project.
Meanwhile https://www.couchbase.com/blog/wp-content/uploads/2021/05/oa...
The diagram on Microsoft's page[1] for that exact same scenario/flow is much clearer IMHO.
[1]: https://learn.microsoft.com/en-us/entra/identity-platform/v2...
The first diagram is literally all over, with just small labels to remind you that this box over here relates to that box over there.
The Microsoft diagram clearly show the parties involved, who they communicate with and in which sequence.
As I mentioned in another post, I found the MS pages very helpful to understand OAuth 2.0, and the clear diagrams was a large part of that.
The PGP packet has entered the chat.
Still have scars from building directly based off the blogposts Twitter and Facebook engineers wrote about how to integrate with this. Think it wasn’t even a standard yet.
I credit that painful experience with now feeling like OAuth is really quite simple. V2 cleaned it up a lot
It doesn’t seem that way on the surface. But once your finished with out of band callback validation, localhost, refresh tokens, and PKCE, you realize what a monster OAuth 2 actually is.
That said, there's a lot of details that are non-trivial, especially since in many cases you actually have to deal with OIDC[2] which builds on OAuth 2.0, and so then you're suddenly dealing with JWKs and whatnot in addition.
[1]: https://learn.microsoft.com/en-us/entra/identity-platform/v2...
"OAuth is a simple idea, but with a curse: once you understand it, you lose the ability to explain it."
If you start with OAuth from the perspective of a Service Provider/resource holder, it will all come clear.
Web security is often like that as well, most people facing stuff like CORS or HTTPS, is usually not because they are trying to solve a security issue, but it's because an upstream provider is forcing them to increase their security standards in order to be trusted with their user's data.
I'm partial to this piece[1], which I helped write. It covers the various common modalities of OAuth/OIDC. (It's really hard to separate them, to be honest; they're often conflated.) Was discussed previously on HN[2].
0: https://news.ycombinator.com/item?id=47100073
1: https://fusionauth.io/articles/oauth/modern-guide-to-oauth
I am seeing many fintech vendors move in this direction. The mutual clients want more granular control over access. Resource tokens are only valid for a few minutes in these new schemes. In most cases we're coming from a world where the same username and password was used to access things like bank cores for over a decade.
Author managed to simultaneously praise the question and avoid answering it at all.
A classic explainer from almost a decade ago. This explains it from the point of view of the original problem it was designed to solve.
I remember how stoked I was to finally get it working. It was a massive pain, but luckily there were websites that would walk through the process procedurally, showing how everything worked, one step at a time.
This page might have something, but I can’t read it myself on mobile cause it shows up broken: https://openid.net/certification/certified-openid-relying-pa...
I know it’s not just OAuth but OIDC had a pretty decent provider support and I could even self-host a Keycloak instance - it was annoying to setup but worked okay in practice, could define my own users and then just get a decent login page when needed and otherwise just got into the sites I wanted.
Personally though, it felt a bit overkill when compared to basicauth for anything not run in public or for a lot of users.
It's pretty neat since you can have one oauth instances for all virtual hosts, e.g.:
server {
[...]
location /oauth2/ {
proxy_pass http://127.0.0.1:8469;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Scheme $scheme;
proxy_set_header X-Auth-Request-Redirect $request_uri;
}
location / {
auth_request /oauth2/auth;
error_page 401 = /oauth2/sign_in;
[...]
}
}
What I need is to understand why it is designed this way, and to see concrete examples of use cases that motivate the design
It's not "just another" explanation for how OAuth does, which was my immediate guess when reading the title.
However glad I opted to give it a chance, and likely especially illuminating for the younger crowd who didn't get to experience the joys of the early web 2.0 days.
Spoiler alert: it is.
This might the best collection of resources:
OAuth is just a process framework for doing authentication and authorization such that a system doesn’t need to create those mechanisms themselves but can ask a server for it. More recently, in the form of a JWT token with those permissions encoded within.
It all boils down to how long your login token (some hash), or in the case of OAuth, your refresh token, can request an access token (timeboxed access to the system). “Tokens” in this case are just cryptographic signatures or hmac hashes of something. Preferably with a nonce or client_id as a salt.
Traditional login with username and password gives you a cookie (or session, or both) that you use to identify that login, same thing for refresh tokens. Only, refresh tokens are authentication, you need access so you request an access token from a resource server or api, now you have your time boxed access token that allows you to “Authentication: Bearer <token>” at your resource.
From a server perspective, your resource server could have just proxied the username and password auth to get the refresh token or (what I like to do) check the signature of the refresh token to verify that it came from me. If it did, I trust it, so long as the user isn’t in the ban table. If it’s good and they aren’t banned, issue them a time boxed access token for 24h.
If you fail to grasp the JWT aspect, I suggest you learn more about RSA/PKI/SHA and HMAC encryption libraries in your programming language of choice. Knowing how to bcrypt is one thing, knowing how to encrypt/sign/verify/decrypt is The Way.
(Sorry to the grey beards in the back and they know this already and probably wrote that RFC).
Most importantly, OAuth is an authorization framework, OIDC is an authentication extension built on top.
Refresh tokens are part of authorization, not authentication.
HTTP header is Authorization: Bearer..., not Authentication.
There's no such thing as "HMAC encryption", it's a message authentication code. RSA in OAuth is also typically used for signing, not encryption. Not much "encryption" encryption going on in OAuth overall TBH.
Nonce and client IDs are not "salts", but ok that's nitpicking :)
The point I was trying to make at 2am is that it’s not scary or super advanced stuff and that you can get away with OAuth-like (as so many do). But yes, OAuth is authorization, OIDC is authentication. The refresh token is an authorization but it makes sense to people who have never done it to think of it as a “post-login marker”.
I've seen so many integrations use Oauth where it wasn't a good fit or where the spec was not followed. It always results in an abomination and insecure mess.
Maybe it's a know the rules before you can break them thing, but I've found designing custom auth integrations from UX first perspective result in amazing features. It's rare that both parties are willing to put the effort in it though. Usually people try to shoehorn the usecase into an existing oauth platform.
The main selling point of Oauth is to scale auth and authz to thousands of clients and use cases.