where is the "session fixation" / token hijacking attack graphic? The history of 1.0 and the rush to put out OAuth 1.0a I will always remember. The year was 2008 and us yammer engineers implemented this new best practice auth system. It went live. And then suddenly a few days later someone in the office proved how the hijack was possible.
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.
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 well written and helped me understand quite a bit. I think a pkce edition would be appreciated considering how prevalent and recommended it is.
I don't think the part about front and back channels is quite correct. GET and POST requests are both encrypted in HTTPS -- including the URL (but not the domain, as DNS resolution happens separately). Front and back channel are more to do with trust boundaries, and what information is public vs private from the client's perspective.
IMO OAuth2 is very poorly designed. It has several structural issues: "Connect this OAuth provider" hijack your main account, redirect hijack allows to leak either auth codes through Referrer or access_token through #hash passing, "state" CSRF token is optional and usually ignored etc
I have an old writeup on that and solution to it https://sakurity.com/oauth - better analyze it with LLM if interested in authorization protocols
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.
Also agree with some of the comments here that majority of articles about OAuth are incredibly verbose, but really hard to actually implement without concrete examples.
I personally think having Curl requests as part of the examples would solve this problem.
17 comments
[ 6.6 ms ] story [ 32.8 ms ] threadI'm glad this analogy was used ... because I too feel like OAuth and Open Banking is effectively the same thing.
Am I alone thinking that and/or why is it actually two different things?
I have an old writeup on that and solution to it https://sakurity.com/oauth - better analyze it with LLM if interested in authorization protocols
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.
Please write follow ups exploring other OAuth flows.
this is not correct with HTTPS (query params are not part of the plain text)
I personally think having Curl requests as part of the examples would solve this problem.