3 ms·
> Relying on plain OAuth 2.0 for authentication is dangerous if you (the client) are just trusting ANY valid access token you receive that's associated with tha
by koolba 3y ago
> Relying on plain OAuth 2.0 for authentication is dangerous if you (the client) are just trusting ANY valid access token you receive that's associated with that user as a reliable indicator that you're receiving the request from the actual user, without knowing whether that access token was generated by the user trying to log into your site or if it was generated by the user logging into some other (malicious) website/app.
That’s why there’s a “state” param that is passed between the source and the identity provider. It validates that the request indeed came from your system. Combined with prop CSRF protection you can ensure the user willfully logged into the system and the response from the IdP was intended for your system.
- deleted 3y ago[deleted]
- cereal_cable 3y agoI'm pretty confident you're wrong there. The state param mentioned is a part of PKCE to verify to the originating source code that you've received the code. The original source of the request then can use that state and compare it to the starting request (or even use it to look it up) and then generate a verifier code to send to the token endpoint along with the code to exchange for tokens. This attempts to prevent a MITM attack by keeping something secret. I believe what you are actually wanting to discuss is the aud claim, or rather the audience claim.
- littlecranky67 3y agoThe article that is linked in the SO post actually makes exactly that point: > Some people believe that using the state parameter in OAuth protects against token substitution. The only binding a browser cookie to state protects against is Cross Site Scripting. Note that I am not arguing about this point as I don't understand nearly enough about OAuth/OIDC, just pointing out this has been adressed in the article.