←back to thread

An illustrated guide to OAuth

(www.ducktyped.org)
354 points egonschiele | 4 comments | | HN request time: 0.21s | source
1. homakov ◴[] No.45015012[source]
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

replies(1): >>45015919 #
2. ted_dunning ◴[] No.45015919[source]
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.

replies(2): >>45016046 #>>45034514 #
3. homakov ◴[] No.45016046[source]
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.

4. derangedHorse ◴[] No.45034514[source]
His comments are also outdated. Browser binding with a separate nonce is standard practice by big identity providers, redirect uris are typically strictly validated, implicit flow without pkce is being phased out, and most browsers protect against a lot of would-be csrf attacks with strict samesite cookie headers.