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

31–40 of 65 posts

Re: An illustrated guide to OAuth

#31

Post by homakov »

ted_dunning wrote: post #29
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.

I wasn’t criticizing the guide — just pointing out real OAuth2 pitfalls that still affect users.

The spec itself made mistakes:

• Silent account hijack via “Connect this provider.”

• Redirect leaks of code (via Referrer) or access_token (via #hash).

• CSRF because state was optional and often ignored.

The point is: these aren’t obscure edge cases, they’re structural issues baked into the protocol.

Re: An illustrated guide to OAuth

#32

Post by [deleted] »

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…

[deleted]

Re: An illustrated guide to OAuth

#34

Post by znpy »

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…

oauth is one of those things i've studied, re-studied, implemented and re-implemented multiple times in my work life and i always end up forgetting it.

at this time I keep a copy of rfc6749 binded and highlighted near my desk... every now and then i have to go look at some detail.

also, somehow the openid spec is a bunch of documents that aren't really formatted for being printed. it really feels like the authors are implicitly assuming no one is going to actually read them.

Re: An illustrated guide to OAuth

#35

Post by OkayPhysicist »

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 page :

https://infosec.mozilla.org/guidelines/iam/openid_connect.ht...

Was by far the most useful information about OIDC I could find when I was implementing an integration.

Re: An illustrated guide to OAuth

#36

Post by manojlds »

OkayPhysicist wrote: post #35
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 page : https://infosec.mozilla.org/guidelines/iam/openid_connect.ht... Was by far the most useful information about OIDC I could find when I was implementing an integration.

I haven't seen the OP yet...are you saying the OP is not worth it and recommending these other links?

Re: An illustrated guide to OAuth

#37

Post by chankstein38 »

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…

I also don't understand the reason but this is my experience on 80% of the internet basically. Articles that purport to share how to do something then spend most of the article talking about stuff I don't care about, then we finally get to the complicated part then they skip some detail or use some library that I don't want to use and then they're just like "bam it's done! woo"

Re: An illustrated guide to OAuth

#38

Post by OkayPhysicist »

manojlds wrote: post #36
OkayPhysicist wrote: post #35

Earlier quoted context omitted.

This page : https://infosec.mozilla.org/guidelines/iam/openid_connect.ht... Was by far the most useful information about OIDC I could find when I was implementing an integration.

I haven't seen the OP yet...are you saying the OP is not worth it and recommending these other links?

OP is largely conceptual. You won't be able to read OP and go write an integration yourself. My link contains all the information necessary to actually implement an OIDC integration.

Re: An illustrated guide to OAuth

#39

Post by Pet_Ant »

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…

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.

Re: An illustrated guide to OAuth

#40

Post by aszen »

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.

Main point is that the url is store in browser history and is never private.
Post reply on HN