Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An illustrated guide to OAuth

ducktyped.org

Post reply on HN
Print view View original

11–20 of 65 posts

Re: An illustrated guide to OAuth

#11

Post by jwr »

gethly wrote: post #3

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 e…

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

Re: An illustrated guide to OAuth

#12

Post by gethly »

aurecchia wrote: post #4
gethly wrote: post #3

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 e…

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. What mig…

I am implementing oauth server with open id provider capabilities. I agree with what you sad, that is my experience as well.

Re: An illustrated guide to OAuth

#13

Post by TofuLover »

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.

Re: An illustrated guide to OAuth

#14

Post by gethly »

jwr wrote: post #11
gethly wrote: post #3

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 e…

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 f…

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

Re: An illustrated guide to OAuth

#16

Post by mettamage »

gethly wrote: post #12
aurecchia wrote: post #4

Earlier quoted context omitted.

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. What mig…

I am implementing oauth server with open id provider capabilities. I agree with what you sad, that is my experience as well.

So how are you guys finding this illustrated guide, is it any good?

Re: An illustrated guide to OAuth

#17

Post by jwr »

gethly wrote: post #14
jwr wrote: post #11

Earlier quoted context omitted.

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 f…

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

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.

Re: An illustrated guide to OAuth

#18

Post by cathalc »

TofuLover wrote: post #13

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.

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

Re: An illustrated guide to OAuth

#19

Post by 7bit »

fcpguru wrote: post #2

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.

Why is that relevant. We are at OAuth 2.0. who cares about what's been 17 years ago?

Re: An illustrated guide to OAuth

#20

Post by mdaniel »

politelemon wrote: post #10

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.

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

1. r = randomInt()

2. future = base64(sha256(r))

3. /authorize?client_id=cid-123&code_challenge_method=S256&code_challenge=${future}

The server has to retain the ${future} in durable storage, because it's going to need access to it, plus the ${code} that it's about to return, in step 5

4. 5. /token?code=abc789&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

Post reply on HN