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.
EthanHeilman · 2m ago
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
fmbb · 2m ago
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.
aurecchia · 1h ago
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.
Before I knew about Keycloak, I need to figure out how to use Spring Boot to authenticate via Azure Entra Id. I could't use Spring Boot Security OAuth2 as I couldn't figure out how to bind Entra ID groups to roles in Spring Boot. I saw a great video from Okta where they broke down all details down to each http request (don't remember the link to the video), and then implement each http request/redirects to Entra ID. Finally I got the token and could then use the Graph API to get group memberships for binding a Spring Boot role.
I still used Spring Sessions though, where a successfull authed user got a new Spring Session. The reason was that I liked the idea of having beans with session scope, for example where each user/role has access to a specific database schema.
peterldowns · 1h ago
Ancient, but potentially also helpful due to documentation and tests, is my old django implementation: https://github.com/peterldowns/djoauth2 . I’m sure it doesn’t run out of the box anymore due to Django changes but maybe another good reference server.
gethly · 52m ago
I am implementing oauth server with open id provider capabilities. I agree with what you sad, that is my experience as well.
mettamage · 22m ago
So how are you guys finding this illustrated guide, is it any good?
commandlinefan · 1h ago
> Are you implementing an auth server or integrating with one?
And OAuth has somehow managed to be _harder_ to integrate with an existing implementation of than just to implement from scratch.
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).
gethly · 46m ago
> the refresh tokens should theoretically not expire
That is subjective. In essence, they should last long enough so the client can use them to get new access token without the user(resource owner) having to authorise a new grant. Each client is different with different needs and the scopes might be too sensitive to provide a long lasting access. So as usual, it depends.
In my server implementation, access tokens are valid for one hour and refresh tokens for 30 days. I also return refresh tokens with each access token request, so as long as the client makes at least one request per month, they do not have to bother the user for a new grant.
I just wish the spec would have a dedicated "refresh_expires_in" field in addition to "expires_in" for refresh tokens, so the client would be better informed about this. As refresh tokens are part of the spec, though optional, their life span information is lacking here.
jwr · 12m ago
Yes, I have no problem with refresh tokens expiring, but I wish the RFC did explicitly include this functionality along with a "refresh_expires_in" field, as you wrote.
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.
cathalc · 12m ago
Yeah this made zero sense to me - I have never seen someone consider POST secure because it can't "be seen".
Security through obscurity and all that...
politelemon · 1h ago
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.
mdaniel · 2m ago
Depending on if you're shopping for the server or the client side of the implementation, I actually found the RFC's example section was actually helpful https://datatracker.ietf.org/doc/html/rfc7636#appendix-B The only thing that jammed me up, even while preparing this comment, is that they named both parameters very similar to one another which is :-(
One can think of the whole exchange as a way for the client to prove future knowledge, but only actually transmitting the held back "secret" during token redemption. Let's use just a random integer
Now, the server can repeat that same sha256 dance from step 2 and establish that the client presenting "r" means it really was the same requester in step 3, because no one else, even with that same IP address and same access to the client_id sniffed in transit, could have known "r" for sufficiently random values of "r", thus proving their key during code exchange
ttb-2134 · 44m ago
This is one of the best OAuth explainers out there. Amazing
tiffanyh · 1h ago
> The example I'm going to use is YNAB. If you haven't used it, YNAB is like a paid version of Mint.
I'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?
fcpguru · 2h ago
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.
7bit · 7m ago
Why is that relevant. We are at OAuth 2.0. who cares about what's been 17 years ago?
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
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.
I still used Spring Sessions though, where a successfull authed user got a new Spring Session. The reason was that I liked the idea of having beans with session scope, for example where each user/role has access to a specific database schema.
And OAuth has somehow managed to be _harder_ to integrate with an existing implementation of than just to implement from scratch.
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).
That is subjective. In essence, they should last long enough so the client can use them to get new access token without the user(resource owner) having to authorise a new grant. Each client is different with different needs and the scopes might be too sensitive to provide a long lasting access. So as usual, it depends.
In my server implementation, access tokens are valid for one hour and refresh tokens for 30 days. I also return refresh tokens with each access token request, so as long as the client makes at least one request per month, they do not have to bother the user for a new grant.
I just wish the spec would have a dedicated "refresh_expires_in" field in addition to "expires_in" for refresh tokens, so the client would be better informed about this. As refresh tokens are part of the spec, though optional, their life span information is lacking here.
Security through obscurity and all that...
One can think of the whole exchange as a way for the client to prove future knowledge, but only actually transmitting the held back "secret" during token redemption. Let's use just a random integer
1. r = randomInt()
2. future = base64(sha256(r))
3. /authorize?client_id=cid-123&code_challenge_method=S256&code_challenge=${future}
4. <-- &code=abc123
5. /token?code=abc123&code_verifier=${r}
Now, the server can repeat that same sha256 dance from step 2 and establish that the client presenting "r" means it really was the same requester in step 3, because no one else, even with that same IP address and same access to the client_id sniffed in transit, could have known "r" for sufficiently random values of "r", thus proving their key during code exchange
I'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?