Are you talking about the PKCE variant of authorization code flow which is what replaces implicit flows in native apps and SPAs? Because those use code_challenge and code_verifier fields, not the state field. If you're doing all that in the state field with signed nonces you really should move to PKCE.
[1] includes info on this (see "flawed CSRF protection")
[0]: https://www.digitalocean.com/community/tutorials/an-introduc...
Thanks!
[1]: https://openid.net/specs/openid-connect-discovery-1_0.html
> that's not correct in the most common flow?
No, he's right, I was misremembering (assuming "the most common" flow is the "authorization code" flow specified in RFC 6749 §4.1). The user-agent provides a one-time "authorization code" to the client via a GET, and then the client receives that "authorization code" and does its own POST to the IDP to exchange that "authorization code" for the final "access token".
> They can't inject a token because you don't get the token from them, just the one time code.
that's not correct in the most common flow? The most common flow involves the user agent providing the information via a GET, so they can theoretically provide a token.
The reason the state parameter is important is because without it, a malicious actor can make a link that goes directly to your system's "oauth step finalized" step, but with their credentials. (Pedantic attack: service has slack push notifications integration, through OAuth. Attacker creates link like https : //service/connect-slack-finalize?token=token-to-attackers-slack that victim clicks on. Without using state, the service will just take the token and stick it into some slack integration. now attacker's slack is getting messages for the victim's account on the service. Cookies mean that the victim's thing is accepted immediately).