What's OAuth2, anyway?

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

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?

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/

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

Is SAML any better?

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.

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

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

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

good luck

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

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

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

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.

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.

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.

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

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.

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.

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