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

21–30 of 65 posts

Re: An illustrated guide to OAuth

#21

Post by EthanHeilman »

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…

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

Re: An illustrated guide to OAuth

#22

Post by fmbb »

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…

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.

Re: An illustrated guide to OAuth

#23

Post by homakov »

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

Re: An illustrated guide to OAuth

#24

Post by brabel »

7bit wrote: post #19
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?

2.1 is just around the corner.

Re: An illustrated guide to OAuth

#26

Post by pverheggen »

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…

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.

Re: An illustrated guide to OAuth

#27

Post by pwlb »

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…

This is due to many parts of the system being spread across multiple IETF RFCs, which happens as OAuth was improved and made more secure over time. Efforts are underway by combining all important parts into OAuth 2.1, otherwise have a look at FAPI 2.0 security profile for high assuance use cases.

Re: An illustrated guide to OAuth

#28

Post by maxwellg »

pverheggen wrote: post #26
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…

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

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.

Re: An illustrated guide to OAuth

#29

Post by ted_dunning »

homakov wrote: post #23

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

Your comments are so highly abbreviated as to be nearly impossible to understand. I suspect that unintelligibility is leading to it being heavily downvoted.

The addition of the comment about LLMs isn't really helping.

Post reply on HN