What's OAuth2, anyway?

https://www.romaglushko.com/blog/whats-aouth2/

by roma_glushko • 1 year ago

341 88 1 year ago

very 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

7bit3• 1 year ago

As 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• 1 year ago

If 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• 1 year ago

My 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.

TrnsltLife• 1 year ago

I work on it every day and can barely remember...

7bit3• 1 year ago

This 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• 1 year 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• 1 year ago

That matches my experience, and it doesn't help that the RFCs, in trying to explain it, have declared defeat early on.

mdhb• 1 year ago

The oauth 2.1 spec does a lot to bring everything together and simplify things at the same time.

chrysoprace• 1 year 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.

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.

7bit3• 1 year ago

OAuth is authorization only. The part where it is vast is the different mechanics to grant/delegate access. And that's really needed because you need to be able to have Oauth working fo humans and machines where the accessing service can be the app on your phone, or some backend server.

motorest6• 1 year ago

So, what we've learned is that OAuth2 is not a single thing, and that it is too complex.

OAuth specifies multiple authorization flows, each one including independent risk mitigation steps.

In my opinion OAuth2 is not "too complex". It's a subject matter that has intrinsic complexity, but one which isn't that high to be blunt.

Of course people who are oblivious to the subject and just glance at it from a distance might be tempted to dismiss it entirely as too complex. This is indeed a recurring problem in software development circles, where typically developers are too quick to criticize existing work because they don't understand requirements, are oblivious to the problem domain, and do not understand how the problems they don't understand are solved. But this doesn't mean the problem domain is complex or too complex.

There is a reason why this sort of walkthrough is very useful: those who are oblivious to the subject and just glance at it from a distance have a way to walk through the requirements and the happy flow in a easy-to-digest way. Hence the comments that now OAuth2 is actually not that complex, it's the RFCs that specify it that are the problem.

Salgat2• 1 year ago

OAuth's biggest issue is that unless you are regularly working with it, you'll probably forget most of the details once you're done implementing it. Similar story with regex for me, it's not that complex, but when I'm building queries a couple times a year at most, I end up forgetting it mostly. It's not surprising that most folks don't understand it, even if at one point they did in the past.

simonw• 1 year ago

Feature 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• 1 year ago

If 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• 1 year ago

Well, it’s still more approachable than SAML. Our industry is messed up and we wonder why phishing is still a thing.

derangedHorse• 1 year 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.

brabel• 1 year ago

The state can be used to transmit useful data...

Which explains why it's called "state".

adeptima7• 1 year ago

And this is why OIDC and IDPs exists to expand more with nonce, user agent footprints and other validation mechanisms

adeptima7• 1 year ago

Excellent 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

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://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/

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

hd4• 1 year ago

One 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.

tptacek2• 1 year ago

OAuth2 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• 1 year ago

It'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• 1 year ago

I 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

ximm• 1 year ago

If you love it so much, here is another one: https://blog.ce9e.org/posts/2025-01-07-oidc/

dadadad100• 1 year ago

Very 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• 1 year ago

This is my absolute favorite explanation of OAuth 2: https://stackoverflow.com/questions/4727226/how-does-oauth-2...

androiddrew• 1 year ago

It’s funny to see your co-worker make the front page of hacker news.

paulddraper5• 1 year ago

What about…a friend?

er4hn• 1 year ago

As 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.

paulddraper5• 1 year ago

Is SAML any better?

andrewstuart2• 1 year ago

Absolutely 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/ or https://saml.xml.org/saml-specifications

tptacek2• 1 year ago

SAML is much, much worse than OIDC.

https://news.ycombinator.com/item?id=28080553

jcmfernandes• 1 year ago

Give it a try and try to come back with your sanity intact. I dare you :)

It's mess.

jrochkind12• 1 year ago

No. I think SAML(/Shibboleth) was a big influence to OAuth2 (?) and is probably the source of most of what ails OAuth2.

sebazzz• 1 year ago

I actually find it very readable. It was at least readable enough so I could implement an OAuth2 client from scratch in C# as a student.

However after years I still don't understand the technical differences between OpenID Connect and OAuth2. Can a OAuth2 client connect to a OpenID Connect server?

ForHackernews• 1 year ago

OpenID Connect is an extension to OAuth2 and a strict superset of it. All OpenID Connect servers are OAuth2 authorization servers - but not the inverse.

OAuth2 technically only offers "authorization" (granting access to do something), but OpenID Connect adds an "authentication" (who is getting this access?) layer on top of OAuth2 by returning an id_token alongside the authorization_token.

unscaled3• 1 year ago

Open ID Connect is not OAuth. It is not done as part of the IETF, and the OpenID Foundation seems to have slightly lower standards for specs. For instance, specs can be updated with errata sets that go as far as as introducing significant changes in the behavior without changing the version number and then do URL is just magically switched to the new document ("incorporating errata set N") without warning. And to top it off, there is no changelog to be found (or at least I couldn't find it).

The original OAuth 2 RFC is a very easy read and it's clearer than most specs out there. It's certainly far easier to read than any W3C spec.

I think the main issue is that there are too many specs that have been added over the years, and you need to know the right ones to implement. Some specs should be mandatory (like Bearer Token Usage, PKCE, OAuth for Native Apps and Current Best Practice[1] and Browser-based Apps[2] when they come out of draft). Some are useful only for certain use cases (Device Authorization Grant, Token Inspection Endpoint and Token Exchange). Some specs are horrible abominations that would hopefully never be implemented (I'm looking at you RFC 9101 JWT-Secured Authorization Request).

The good news is that OAuth 2.1 incorporates some of the best RFCs I've mentioned into the core RFC. This would help make OAuth simpler by having one document to point out to. I hope it comes out soon, since at this point I still have to fight with people who think that using the Password Grant is a great idea and have no idea why they should implement PKCE or CSRF protection.

[1] https://oauth.net/2/oauth-best-practice/

[2] https://oauth.net/2/browser-based-apps/

adeptima7• 1 year ago

Some specs should be mandatory 100% agree

OpenID Foundation seems took a path of making "profiles" like FAPI rather consolidation and enforcing the best practices and depricating the bad.

FAPI (Financial-grade API Security Profile 1.0) https://openid.net/specs/openid-financial-api-part-1-1_0.htm...

I hope the community will combine it all at some point and add specifications for proper policy and resources management too by looking at the full lifecycle of modern applications.

stuaxo• 1 year ago

Some of the worst times I have had in projects are when I've had to add oauth2.

hi_hi• 1 year ago

Ha, I'm just reading this after tearing my hair out after trying to get a basic omniauth google login working in Rails. I was hitting CORS issues, for hours. I'm new to rails, but had read how productive it makes you. Well, thanks to one of their productivity features (Turbo) I was ready to throw the whole thing out. Yes, I know, this wasn't an oauth2 issue directly. /rant :-)

deepsun• 1 year ago

It 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).

paulddraper5• 1 year 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• 1 year ago

The 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.

paulddraper5• 1 year ago

My 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.

adeptima7• 1 year ago

my 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

PDFBolt3• 1 year ago

Good 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.

adeptima7• 1 year ago

Expand 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?

PDFBolt3• 1 year ago

Yeah, 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

This works well for temporary document access in workflows like report generation, invoicing, and legal docs.

belter• 1 year ago

No discussion of OAuth2 can be done without mentioning it's cursed origins.

Read the Controversy section: https://en.wikipedia.org/wiki/OAuth

Biganon• 1 year 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• 1 year ago

OAuth2 is built to be super simple to implement client applications

Has this fallen through from an alternate dimension?

frogsRnice• 1 year ago

No 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_duffle2• 1 year ago

Or a refresh token (which might be one of those two you mentioned)

jeroenhd• 1 year ago

OAuth2 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• 1 year ago

This 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• 1 year ago

Is oauth the thing that brought on us those applications that have to open a browser window to authenticate you?

mgaunard4• 1 year ago

As 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• 1 year ago

Because 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• 1 year 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• 1 year ago

i want the user to do this very particular thing in an absolutely correct way

good luck

zie• 1 year ago

because 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).

motorest6• 1 year ago

As a non-web person,

Yes, indeed.

I find everything related to this auth business needlessly complicated and arbitrarily limited.

You find a subject you do no understand or were bothered to learn about to be 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 (...)

You seem to be very opinionated over things you clearly know nothing about.

Among the many ways you manifested your cluelessness, OAuth is not a "web dev" thing. It's a "software communicating over a network" thing. Desktop apps must support it, so do mobile apps, and web services need to support it both as client apps and resource services.

Also, to drive home your clueless ignorance, "checking the JWT audience" is not a authentication thing, which is the responsibility of OAuth. The full name of OAuth2 is "OAuth 2.0 Authorization Framework". It covers delegating authorization to third parties so that clients can access a user's claims. Claims are not authorization either.

In the end you were awfully critical of something you don't even know what is?

(...) just use libraries without understand what actually provides the security.

I think you should take a step back and meditate over your post. It says nothing about OAuth, and everything about how little understanding you have over OAuth and how vocal you are on a topic you know next to nothing.

mgaunard4• 1 year ago

I've implemented those components from scratch in C++ to provide single-sign-on authentication across a variety of distributed sensitive applications, without using any libraries, so I'd say I'm fairly familiar with how they actually work.

JWT is by far the most important building block here, and while it's not part of OAuth, realistically it's how anyone sane would use OAuth.

Fats• 1 year ago

Why are you so condescending?

It's always very jarring to come across a post that is so drastically different in tone when you're just trying to follow a comment thread.

I think you should take a step back and meditate over your post.

I wish you'd follow your own advice.

whoknew1122• 1 year ago

The 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• 1 year ago

That was the design intent of OAuth2 - needless complexity to generate consulting and service opportunities

adeptima7• 1 year ago

And 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/

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-p...

If any cyberops, pentester pro reading this, please advise how to research more. Thanx in advance.

jrochkind12• 1 year ago

I 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• 1 year ago

It’s this one thing no one implements correctly ;)

noa775• 1 year ago

noa kistina haker\

voor bihas

What's OAuth2, anyway?

Related Stories