←back to thread

An illustrated guide to OAuth

(www.ducktyped.org)
354 points egonschiele | 1 comments | | HN request time: 0.204s | source
Show context
gethly ◴[] 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 #
jwr ◴[] 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 #
gethly ◴[] 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 #
1. Pet_Ant ◴[] 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.