I am implementing oauth right now, along with oidc. I must say that for such a simple concept, getting to the facts that help me to actually implement it is insanely hard. I have no idea why but everywhere i look it just seems like it only scratches the surface and you get no tangible information that you can use to actually implement it in code. I ended up mostly browsing the specs and grok was insanely helpful to explain meaning of various things where information was lacking or buried deep in documentation/specifications. I would say this was the first time where i actually appreciated these new "AIs", which i don't use at all.

Yes, 100% agreed.

I launched and worked on OAuth 2.0 at Okta for ~5 years and spent most of my time showing people how to do it well and (gently) finding the holes and mistakes in their implementations. Sure, we were selling "OAuth as a Service" but most had introduced usability problems (at minimum) and gaping security vulns (at worst).

For a deep dive, check out Aaron Parecki's book: https://oauth2simplified.com/ - he's deeply involved in the (coming) OAuth 2.1

When I led re-implementation at pangea.cloud over the last couple years, we dropped most of the capabilies deprecated in 2.1 (resource owner password, implicit) and went straight to Auth Code with PKCE to make it a bit more manageable.

I walk through that progression/simplication here: https://speakerdeck.com/caseysoftware/the-many-layers-of-oau...

When I implemented Oauth2 (Authorization Code Grant, both sides), I found this guide to be quite helpful: https://alexbilbie.github.io/guide-to-oauth-2-grants/

One thing I found after a while: even though the refresh tokens should theoretically not expire, many sites do expire them. You have to refresh every once in a while to maintain a usable refresh token.

Many people will tell you to "just use a library", but I found that the contact surface of oauth with your app is quite large, such that a library might not actually help much. This (among other reasons) is why I wrote my own implementation (Clojure).

Are you implementing an auth server or integrating with one?

Regardless, the last time I dug into this topic I ended up feeling the same. The web is littered with articles that scratch the surface and only cover the basics. They often leave out the details, which IME ended up making things more difficult to understand. What was the most helpful, as you said, was to follow the RFCs and the OIDC spec directly.

What might also be useful, if you are implementing an auth server, is to look at existing implementations. Duende IdentityServer (https://github.com/DuendeSoftware/products/tree/main/identit...) is the most widely-used one in the .NET space.

A while ago, I set out to understand OAuth properly and built a fully compliant authorisation server on SvelteKit, following all relevant RFCs, simply by… reading them all.

When you get used to the technical writing, it’s actually pretty straightforward—most of them actually document the endpoint structure and payloads, error codes, and so on. After that, the most complicated part is organizing your code to be modular and handle persistence right.

I can really recommend doing this once, and once the pieces start to fall into place, you’ll be able to understand most OAuth issues you’ll ever come across!

Fantastic comment from an earlier posting https://news.ycombinator.com/item?id=35720336

“… one of the principle issues is that it's less a protocol and more a skeleton of a protocol.”

Yep, I had to get deep into OIDC for OpenPubkey and it basically involved me having to build teaching materials and notes for myself. I had a bunch of Google docs slides I consult every time I got confused about what something did. A major motivation for writing the OpenPubkey paper was to have detailed notes on how OIDC works to remind myself.

I recommend sections I and II of the OpenPubkey paper to anyone trying to understand OIDC public clients. I consult it at least once a month: https://eprint.iacr.org/2023/296

In case it helps you, I found this overview helpful: https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Aut...

Clearly written by someone who was also frustrated by the experience (:

I also don't understand the reason but this is my experience on 80% of the internet basically. Articles that purport to share how to do something then spend most of the article talking about stuff I don't care about, then we finally get to the complicated part then they skip some detail or use some library that I don't want to use and then they're just like "bam it's done! woo"

This is due to many parts of the system being spread across multiple IETF RFCs, which happens as OAuth was improved and made more secure over time. Efforts are underway by combining all important parts into OAuth 2.1, otherwise have a look at FAPI 2.0 security profile for high assuance use cases.

This page :

https://infosec.mozilla.org/guidelines/iam/openid_connect.ht...

Was by far the most useful information about OIDC I could find when I was implementing an integration.

oauth is one of those things i've studied, re-studied, implemented and re-implemented multiple times in my work life and i always end up forgetting it.

at this time I keep a copy of rfc6749 binded and highlighted near my desk... every now and then i have to go look at some detail.

also, somehow the openid spec is a bunch of documents that aren't really formatted for being printed. it really feels like the authors are implicitly assuming no one is going to actually read them.

i did the same last month - i used chatgpt heavily to explain oauth to me. and then confirmed what it was telling me my checking the actual spec documents.

i think, as the article says, oauth is so varied that while there are documents, none of them are tailored enough for your specific use case. but an LLM can narrow it down to exactly your use case, which is what you really need to implement it.

It also seems to react pretty aggressively with the various foibles of different programming languages e.g. I remain stunned how fiddly adding oauth/oidc can be to a dotnet application considering dotnets bread and butter is supposed to be enterprise slop

This is because OAuth is just SAML with JSON designed by committee so it has all the bells and all the whistles and everything is optional and depends on who you integrate with and how.