3 ms·
This post is wrong in many ways. First, you know which app the access token was issued for, it's the "aud" in the JWT. Second, you should at least use the "st
by brabel 3y ago
This post is wrong in many ways.
First, you know which app the access token was issued for, it's the "aud" in the JWT.
Second, you should at least use the "state" parameter on authorization requests so that when you receive the access token via a redirect, you can guaranteee that the user was logging in intentionally and is now completing the flow (rather than coming from an attacker controlled website).
Even better is to use PKCE! It should be common knowledge by now that you must use PKCE[1] if you really want to completely prevent CSRF attacks. OIDC helps with that because it practically makes this a requirement, but you don't need OIDC just for that.
Finally, OIDC is not meant to increase OAuth security as this post tries to imply! It's just a layer on top of OAuth to establish an authentication procedure (OAuth intentionally leaves authentication out of scope as it's focused on authorization protocols). IT does end up improving certain things, but those things can be improved using simple OAuth extensions (like PKCE mentioned), only use OIDC if you actually need user information besides what's in the Access Token.
[1] https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#name-protecting-redirect-based-f https://datatracker.ietf.org/doc/html/draft-ietf-oauth-secur...
- hsbauauvhabzb 3y agoI think this is a fairly elitist view and I disagree. I work in application security and still have trouble understanding all the behaviours of oauth and oidc, even after reading the specs multiple times. If I can’t understand it fully, how are you going to expect some developer who has no security or crypto background implement it correctly when nobody is there to validate the implementation? I feel like the oauth/oidc are insecure not because of the core logic, but because the design and terminology aren’t easily understood - that complexity IS a vulnerability.
- brabel 3y agoMy comment was pointing out mistakes in the claims from OP, I am not sure how you can interpret that as elitist. You may have read something into my comment that I did not say. For example, I didn't say OAuth is simple (though I am still to see a security framework that's better/simpler for the use cases OAuth sets out to solve).
- diarrhea 3y agoThis comment illustrates the issue on a meta level. The GP is a regular developer reaching out for help, raising issues experienced due the complexity of the matter. Very relatable. Along comes this comment's parent, essentially going "this is wrong in many ways, it's so easy if you just...". Very reminiscent of https://news.ycombinator.com/item?id=8863 https://news.ycombinator.com/item?id=8863 . Authentication and authorization need to be simple (enough) and, most importantly, offer a set of sane defaults. It mustn't require years worth of expertise. It is bound to be misused.