10 ms·
What's OAuth2, anyway?
- deleted 2y ago[deleted]
- vivzkestrel 2y agovery comprehensive but i wanted to add. oauth is one of those things i read about and forget 6 months later. there has to be a gamified way to make people learn about oauth and enforce it deep inside their brains
- 7bit 2y agoAs with everything: repetition. If you forget these things you don't use them often enough. On that level, do you really need to remember them or are you happy enough to have a good and short reference, like this article for example? My personal answer is: a cheat sheet is enough.
- taurath 2y agoIf you implement it twice, the sequence diagram tends to get burned into the brain. It’s tricky and you’ll be able to anticipate its trickiness.
- unshavedyak 2y agoMy problem is what part you're implementing can be different. Are you implementing the ability to use someone else as auth? Are you implementing the ability for others to use you as auth? Are you a client, or a server? etc I don't know oauth at all, but that was the area that always felt convoluted when i'd research it. I think i'd be much happier if they had sub spec names with very specific use cases. OAuth2 Client Redirect, OAuth2 Server Authority, or w/e.. i'm just making stuff up for attempted clarity.
- deleted 2y ago[deleted]
- XorNot 2y agoMy problem is that my use case is always this: by default the application should be it's own OAuth server, so the endpoints can use OAuth against the application and a local only database. Then I want an easy story for linking that instead to LDAP for corporate deployments, or to an SSO OAuth server. The problem is...well I still don't really know how I should be including that? It's so much easier just to register a session cookie from a login page.
- jpc0 2y ago> The problem is...well I still don't really know how I should be including that? It's so much easier just to register a session cookie from a login page. For a webpage this makes perfect sense, where would you securely store an access / refresh token on web that isn't vulnerable to XSS? In a session cookie that is secure & http only... For native apps though that state might be more annoying to track and a auth token and refresh token is pretty easy to store securely.
- TrnsltLife 2y agoI work on it every day and can barely remember...
- 7bit 2y agoThis is an excellent article. The only thing I am missing is a short paragraph about OIDC, which is the thing that enables authentication. To most people who just get in touch with the topic OAuth is more authentication than authorization.
- yencabulator 2y ago> Apart from that, OAuth2 is such a vast area that we have been able to only answer the fundamental why questions and review the most popular delegation grants in this article. So, what we've learned is that OAuth2 is not a single thing, and that it is too complex.
- lxgr 2y agoThat matches my experience, and it doesn't help that the RFCs, in trying to explain it, have declared defeat early on.
- mdhb 2y agoThe oauth 2.1 spec does a lot to bring everything together and simplify things at the same time.
- chrysoprace 2y agoIt's also hard to find the relevant RFC, because older RFCs contain grant types that are no longer recommended, but still widely in use. This means that if you're working on a legacy application that's using something like the implicit grant, to actually learn about it, you need to read superseded RFCs.
- motorest 2y ago> It's also hard to find the relevant RFC, because older RFCs contain grant types that are no longer recommended, but still widely in use. Why do you think this is a problem? So old RFCs specify grant types. That's ok, that's the whole point of specifying authentication schemes. Some are not recommended? That's perfectly fine, it just means there are better, safer ways to implement a flow. Are they still widely use? That's great, you already know where they are specified. So what's the problem? > This means that if you're working on a legacy application that's using something like the implicit grant, to actually learn about it, you need to read superseded RFCs. I don't understand. Where do you see a problem? You said you know where a specific flow is specified, and you want to learn it. You even have a implementation? What's the problem? Does a "superseded" tag bother you?
- simonw 2y agoFeature request: at one point in this guide it says: > However, it’s discouraged to use URL fragments as they impose potential security issues. I'd love it if that linked to a footnote or similar that explained what those potential security issues are.
- NewJazz 2y agoIf the user is on a search page, the user's query (which could be argued as private/sensitive data) would be exposed. That's one I can think of.
- goalieca 2y agoWell, it’s still more approachable than SAML. Our industry is messed up and we wonder why phishing is still a thing.
- derangedHorse 2y ago> Practically speaking, the state is just a random non-guessable string that is saved in the client application session It doesn't have to be completely random, the spec only makes partial randomness a requirement: "The binding value used for CSRF protection MUST contain a non-guessable value" --- The state can be used to transmit useful data as long as the data isn't sensitive: "The "state" and "scope" parameters SHOULD NOT include sensitive client or resource owner information in plain text, as they can be transmitted over insecure channels or stored insecurely." This can be used in place of any 'Additional Client Callback URL params'. --- Aside from that, I think this is very well written! I'll share it with others who want to learn more about OAuth 2.0 and its extensions.
- adeptima 2y agoExcellent writing and diagrams! If you want to expand your knowledge beyond OAuth2 (and most probably you should if you want to design systems used by big guys from 0 to 1) , highly recommend to jump straight into OpenID Connect (OIDC) which is an identity layer built on top of OAuth 2.0. Besides reading specs, Sascha Preibisch's videos on both OIDC and OAuth2 were the most useful to solidify a bigger picture for me https://www.youtube.com/@saschazegerman/playlists https://www.youtube.com/@saschazegerman/playlists Specs are actually well written despite of all jargon and train of buzzwords used inside. The most annoying on my list are OP (OpenID Provider) and RP (Relying Party) ... https://openid.net/specs/openid-connect-core-1_0.html https://openid.net/specs/openid-connect-core-1_0.html https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/ https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/ Most useful knowledge however personally gained from studying ORY Hydra mentioned in the article and Zitadel https://zitadel.com/ https://zitadel.com/ The problem with OIDC and OAuth2 space - IDP providers are too "creative" in their interpretation of specs starting from userinfo and token exchange endpoints. Without allocating significant amount of time getting all flows and related cyberops into your brain might never happened. Good news - it's a life time investment ... Oidc search on github gives good results - libraries, open source IDPs, all kind of proxies, etc https://github.com/topics/oidc https://github.com/topics/oidc
- hd4 2y agoOne thing I wish I had learnt early on when I started looking into authentication is that OIDC (ideally with SSO through Google or GitHub) is the protocol/real-world implementation most developers will want to just be able to get started with whereas OAuth2 is more like the (boring) specification. If you're wondering what to use to get authentication working (and not doing something risky), 90% of the time the answer will be OIDC.
- tptacek 2y agoOAuth2 is more general than OIDC, came first, and was intended to solve a smaller problem (delegated access to resources). OIDC is identity (rather than permission) implemented on top of OAuth2.
- throwaway519 2y agoIt's the manifested fear of AOLesque internet silos to hang on to their ~prey~ users by the claw. It creates a less open, less federated web.
- matthewaveryusa 2y agoI love reading blog posts on oauth2 and oidc. I have a mental model on how it works but every person has their own way to describe the flows. So far my favorite article has been oauth-oidc from first principles[1] and why each piece of the protocol is useful. This being hackernews, any comment worthwhile cannot be devoid of criticism. Trust-on-first-use is used incorrectly here -- saving the previous authorization scopes is just caching. TOFU has a specific definition in security: it's when you're establishing a secure channel but you haven't shared a secret or public key a-priori -- it makes it impossible to guarantee that the counter-party is whom they say they are. Very concretely TOFU is a diffie hellman key exchange with a shared secret that can be MitMed. Through use in time the shared secret gains integrity because the probability of a persistent MitM accross channels degrades. The most common place TOFU is encountered is when connecting via ssh to a server and the server accepts your connection because you're in their authorized_keys but the server's key is not in your known_hosts. [1] https://stack-auth.com/blog/oauth-from-first-principles https://stack-auth.com/blog/oauth-from-first-principles
- ximm 2y agoIf you love it so much, here is another one: https://blog.ce9e.org/posts/2025-01-07-oidc/ https://blog.ce9e.org/posts/2025-01-07-oidc/
- dadadad100 2y agoVery good presentation but I do miss any mention of the audience claim. This claim is underrated in my opinion at least. It allows the token to climb access to an api or server or whatever that can be used by gateways to do a high level authorization. Then the scopes can be used at the resource server to govern lower level authorization.
- rfarley04 2y agoThis is my absolute favorite explanation of OAuth 2: https://stackoverflow.com/questions/4727226/how-does-oauth-2-protect-against-things-like-replay-attacks-using-the-security-t/32534239#32534239 https://stackoverflow.com/questions/4727226/how-does-oauth-2...
- androiddrew 2y agoIt’s funny to see your co-worker make the front page of hacker news.
- paulddraper 2y agoWhat about…a friend?
- er4hn 2y agoAs an Oauth2 hater, I consider this protocol cursed, mainly due to how hard it is to read through all the specs and have a useful understanding of what one should do with it. Reading the OIDC spec, where they define authN in terms of authZ, lets me experience what a stroke must feel like.
- paulddraper 2y agoIs SAML any better?
- andrewstuart2 2y agoAbsolutely not. Read the specs [0] there as well if you truly want to know. XML canonicalization is a special kind of hell that I've done once and wish to never do again. And the enveloped signatures of xmldsig are also pretty complicated to get right. And it's a wild west as to how the specs are implemented on RPs and IDPs alike (more so, in my experience, than OIDC by a long shot). [0] https://www.oasis-open.org/standard/saml/ https://www.oasis-open.org/standard/saml/ or https://saml.xml.org/saml-specifications https://saml.xml.org/saml-specifications
- paulddraper 2y ago(I know, agreed. Rhetorical.)
- tptacek 2y agoSAML is much, much worse than OIDC. https://news.ycombinator.com/item?id=28080553 https://news.ycombinator.com/item?id=28080553
- jcmfernandes 2y agoGive it a try and try to come back with your sanity intact. I dare you :) It's mess.
- tolien 2y ago
- deepsun 2y agoIt always says OAuth2, even though it's all about OAuth in general. OAuth v1 was doing exactly the same, just different implementation detail (e.g. v2 relies on HTTPS, while v1 forced you to sign tokens so no need to encrypt).
- paulddraper 2y ago> So they generalize the discovery approach from OpenID Connect specification into RFC8414 that adds a new metadata route under .well-known subpath. That route contains URLs of the authorization and token endpoints, supported token authentications, OpenID user URL, etc. “Yo I heard you like URLs so I made URLs for your URLs.” But seriously…if you’re going to have fixed URLs, why not just have fixed URLs for these endpoints? What does the indirection get you?
- hobofan 2y agoThe indirection gets you simplicity during integration, as in the optimal case the consumer only has to point to a single URL than to a handful, and rest of the URLs can be auto-discovered from there. Also if you look at the typical endpoints you see listed there you'll find that they are usually pre-existing oauth2 endpoints that predate OIDC, so by not requiring the creation / new routing of those endpoints, OIDC adoption is easier on the OIDC provider side. And lastly you'll need the metadata endpoint anyway for all the non-URL data that is exposed by that endpoint.
- paulddraper 2y agoMy point is that if you require /.well-known/openid-configuration to tell your the OAuth URLs, why not just require the OAuth URLs to be /.well-known/openid/authorize /.well-known/openid/token > by not requiring the creation / new routing of those endpoints, OIDC adoption is easier on the OIDC provider side. Redirects exist though. We already have the technology, we already have the protocols, we're just inventing more stuff that we already have.
- adeptima 2y agomy guess the idea and intension of .well-known was good, so generic end-user libraries can be implement ... the reality is ugly and generate lot of man hours for cyberops consultancies
- PDFBolt 2y agoGood breakdown! OAuth2 is one of those things that feels simple until you actually have to implement it. Curious how do you see OAuth2 fitting into workflows where users need to generate and securely access documents, like PDFs? We’ve found that balancing ease of access with security (especially for things like temporary document URLs) can get tricky.
- adeptima 2y agoExpand to OIDC and use session based mechanism with some kind of policy engine? Never saw a good example of how to implement a proper access to pdf or other downloadable documents. What is your approach? Any good code base in open source to learn from?
- PDFBolt 2y agoYeah, OIDC with session-based access makes sense, especially for enforcing policies dynamically. For secure PDF access, we’ve found pre-signed URLs to be a solid approach. They allow temporary, controlled access without requiring ongoing authentication. Here’s a simple example using AWS S3 (or any S3-compatible storage) to generate a pre-signed URL for a PDF: https://github.com/pdfbolt/generate-s3-presigned-url https://github.com/pdfbolt/generate-s3-presigned-url This works well for temporary document access in workflows like report generation, invoicing, and legal docs.
- adeptima 2y agoThanx for sharing! What if pre-signed URL is leaked, you cannot invalidate a pre-signed URL without rotating credentials or changing bucket policies, right? I was thinking about signed cookies or API gateways type of solutions.
- PDFBolt 2y agoYou're right. Pre-signed URLs can’t be revoked once issued, but one way to mitigate the risk is by setting a short expiration time when generating them. For example, if the URL is only valid for 5-10 minutes, it remains secure, and the risk of misuse is minimal.
- belter 2y agoNo discussion of OAuth2 can be done without mentioning it's cursed origins. Read the Controversy section: https://en.wikipedia.org/wiki/OAuth https://en.wikipedia.org/wiki/OAuth
- Biganon 2y ago> Have you ever logged into a website using your Google or Facebook account? Or connected an app to access your GitHub data? If so, you’ve already used OAuth2, whether you knew it or not. Or SAML. Had to implement SAML at work recently.
- andybak 2y ago> OAuth2 is built to be super simple to implement client applications Has this fallen through from an alternate dimension?
- frogsRnice 2y agoNo you misunderstand- it is super simple to pay some other company a small amount to do this for you. No complexity to worry about what so ever. And if things require even a slim amount of thought and planning - chuck it to your favourite LLM and call it a day. Just in case the sarcasm wasn’t clear I want to personally assure you that nobody ever will confuse an access token for an ID token. :p
- cruffle_duffle 2y agoOr a refresh token (which might be one of those two you mentioned)
- jeroenhd 2y agoOAuth2 is a very simple method to solve a very complex problem. Every part of it has a good reason to exist. Unfortunately, OAuth2 is also used by applications that don't actually have the complex problems OAuth2 is trying to solve, which makes it look unnecessarily complex. Thankfully, just about every language and framework has OAuth2 libraries available so you can use it by copy/pasting four strings, whether it's a good fit or not. That's probably why it's overused as well, to avoid difficult integrations of simpler, custom schemes.
- ChicagoDave 2y agoThis is by far the most elegant and thorough write up of OAuth2 I’ve ever read. I’d go so far to consider this canonical. Bookmarked!
- nottorp 2y agoIs oauth the thing that brought on us those applications that have to open a browser window to authenticate you?
- mgaunard 2y agoAs a non-web person, I find everything related to this auth business needlessly complicated and arbitrarily limited. Most of the time it's not even implemented correctly anyway (many application not checking the JWT audience...) because web devs just use libraries without understand what actually provides the security. As an application writer, I want the user to feed me a token signed by a trusted entity that proves he is who he claims he is and has the necessary accesses enabled for my application. Whether this happens transparently via a redirect to the trusted entity login webpage and back to my app or whether I request the user to go to a specific url on their own while I wait for them to do so is just an UX detail. Why every approach needs to be labeled a "flow", authorized separately, and come with their own limitations is beyond me.
- L-four 2y agoBecause web browsers are a massive hack and nothing works 100% so theres 10 different flows to cover which sort of broken is acceptable to your use case.
- PeeMcGee 2y ago> Whether this happens transparently via a redirect to the trusted entity login webpage and back to my app or whether I request the user to go to a specific url on their own while I wait for them to do so is just an UX detail. Why every approach needs to be labeled a "flow", authorized separately, and come with their own limitations is beyond me. The reason they're called flows is because they each compose one or more single steps from the OAuth2 "toolbox" (i.e. endpoints). Many flows will have overlapping or even identical "steps", but the order of things matter and the modes in which they interact matter, which is why the second layer of delineation is necessary (or useful, at least).
- kkarakk 2y ago>i want the user to do this very particular thing in an absolutely correct way good luck
- zie 2y agobecause web server, browser and protocol developers, after implementing HTTP Basic Auth punted and said this is gross and hard. They then gave up on the problem. The problem still existed, and other developers took a stab, but they weren't protocol or cryptography people, so we got a bunch of mostly broken stuff. Some cryptographers came along and pointed out the disasters, and since then it's been slowly getting better, but it's still a giant mess. Companies have decided, since we have to solve it for us, we can just solve it for you too, and now we have "social logins" where we tell Microsoft, Apple or Google everything we login to. They appreciate the extra information to help themselves, so it's a worthwhile incentive for them. The web browser developers got a little involved with passkeys, but the UX is still not idiot proof. Better than their last two tries at implementing public key auth though(TLS client certs and DOD auth).
- whoknew1122 2y agoThe best thing I can say about OAuth is that--as an identity dude--it keeps me gainfully employed. If only because people often implement it incorrectly.
- klysm 2y agoThat was the design intent of OAuth2 - needless complexity to generate consulting and service opportunities
- adeptima 2y agoAnd by the way, has anyone researched on GNAP (published 20 March 2024)? > GNAP (Grant Negotiation and Authorization Protocol) is an in-progress effort to develop a next-generation authorization protocol From spec https://oauth.net/gnap/ https://oauth.net/gnap/ > GNAP is not an extension of OAuth 2.0 and is not intended to be directly compatible with OAuth 2.0. GNAP seeks to provide functionality and solve use cases that OAuth 2.0 cannot easily or cleanly address. > GNAP and OAuth 2.0 will likely exist in parallel for many deployments, and considerations have been taken to facilitate the mapping and transition from existing OAuth 2.0 systems to GNAP Doesnt look like GNAP will fly any time soon, however there is a very interesting part - Security Considerations section. Looks like it was made by people who are familiar with all varieties of cyberops and usability issues in OAuth2/OIDC spec. Security Considerations section https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol#name-security-considerations https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-p... If any cyberops, pentester pro reading this, please advise how to research more. Thanx in advance.
- jrochkind1 2y agoI think they tried to make OAuth(2) too flexible, and to me the lesson -- and I wonder if this is commonly understood this way or not -- is that it's preferable to make very simple clear limited-scope standards for clear use cases, even if that means they won't be able to meet all use cases. And then add on (even possibly in additional separate standards) for other use cases, after the first has been succesful. With what we actually have, my impression (curious if others with more experience can confirm) is that you have to get lucky for different OAuth2 implementations to even be interoperable?
- andix 2y agoIt’s this one thing no one implements correctly ;)
- noa775 2y agonoa kistina haker\ voor bihas
- svereecke 2y ago[dead]