An illustrated guide to OAuth

Point of order: first, OIDC is SAML, not OAuth (OAuth by itself solves a different problem) and second, OIDC is much better than SAML --- the committee did its job there.

This is a pretty good guide! I didn't get any AI slop vibes from it, so I'm assuming it was handwritten, which I appreciate.

I think I would suggest that PKCE is not really "less secure" than a client secret. It serves somewhat of a different purpose, and is actually frequently recommended even with a client secret. Its main purpose is "flow integrity" and ensuring that the same client is involved all the way through the redirects.

I think it also didn't really put the authorization code grant in context with the other possibilities. This really covered the "3 legged redirect" flow pretty well, which is what most people associate with OAuth. But the OAuth2 framework has a bunch of different grants you can use for different purposes. The Client Credentials one is pretty common, for server-to-server use cases, as well as fancier versions of it like the JWT Bearer flow.

Finally, taking an advantage of general OAuth2 discussion, since I've been noodling on it myself from the point of view of creating an "app ecosystem": since the redirect_uri is such an integral part of the security of it, and recommendations are for exact matches now rather than just prefixes and wildcards and such, how do folks handle OAuth2 when the app isn't owned by a single entity, but rather something like ServiceNow or Backstage which is self-hosted?

That is, you want your resource server to behave like "this was a request from a customer's ServiceNow instance", and all such requests are in some sense related. However, they're not really the same client, because you can't manage a client secret across all the installations. It's somewhat like a mobile app, which also can't manage a client secret, but that at least can share the same underlying OAuth Client because it can register a single, unique redirect URI.

I have other questions about things like how to fit the client credentials grant into a multi-tenant system... if these are things you've worked on, I'd love to hear from you! My email should be on my profile here.

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

You can't. It is just a matter of reducing the risk surface. With a GET someone may add parameters, with a POST they would send the data in the post (which is often the main point of a POST).

Since all typical web servers/processors only loh the call and not the body there is a lesser probability of a leak.

I am writing this as someone who manages cybersecurity and is offering faced with not enough information in investigations because of that. This is also the reason that I used "typical" and "usually" above - it is pretty weird what people send and how they process what they receive.

Very clearly written article.

Please write follow ups exploring other OAuth flows.