←back to thread

An illustrated guide to OAuth

(www.ducktyped.org)
354 points egonschiele | 6 comments | 25 Aug 25 12:29 UTC | HN request time: 0.446s | source | bottom
Show context
gethly ◴[25 Aug 25 13:31 UTC] No.45013667[source]▶
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.
replies(15): >>45013786 #>>45014191 #>>45014923 #>>45014925 #>>45015705 #>>45016116 #>>45016464 #>>45016521 #>>45016761 #>>45017703 #>>45017714 #>>45018132 #>>45018714 #>>45019295 #>>45021989 #
1. jwr ◴[25 Aug 25 14:23 UTC] No.45014191[source]▶
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).

replies(2): >>45014435 #>>45015654 #
2. gethly ◴[25 Aug 25 14:44 UTC] No.45014435[source]▶
> 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.

replies(2): >>45014815 #>>45017046 #
3. jwr ◴[25 Aug 25 15:18 UTC] No.45014815[source]▶
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.
4. pverheggen ◴[25 Aug 25 16:30 UTC] No.45015654[source]▶
FWIW, this is fairly out of date - password grant must not be used and authorization code should be used in place of implicit. I highly recommend anyone dealing with OAuth to read the BCP and not just the spec, especially if you're rolling your own:

https://datatracker.ietf.org/doc/html/rfc9700

As for your API surface, typically you'd handle this at the gateway level, then individual services don't have to perform authorization.

replies(1): >>45015904 #
5. maxwellg ◴[25 Aug 25 16:52 UTC] No.45015904[source]▶
I would also recommend the OAuth 2.1 IETF draft as a precursor to the BCP: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-...

Although it isn't a published RFC yet, it intends to replace several sometimes-conflicting previous RFCs + the BCP with a single document.

6. Pet_Ant ◴[25 Aug 25 18:19 UTC] No.45017046[source]▶
How hard is it to get a suggestion like that in? I mean it seems fool proof, make it optional and there should be no problem.