3 ms·

That's something that isn't OAuth2 or your end point is accepting something insane. Are you talking about the PKCE variant of authorization code flow which is

That's something that isn't OAuth2 or your end point is accepting something insane. 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.

rtpg 3y ago
Using [0] as a reference, I'm talking about Step 3. This is, in my experience, the "normal" way that people are setting up OAuth between 2 services, with a user going through the flow. [1] includes info on this (see "flawed CSRF protection") [0]: https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2#step-3-application-receives-authorization-code https://www.digitalocean.com/community/tutorials/an-introduc... [1] https://portswigger.net/web-security/oauth https://portswigger.net/web-security/oauth
- krinchan 3y ago
  Aha! That makes sense! Yes that can be a problem. We exclusively use a single (our own) IdP so it's less important for us. But good to know as some future feature work will actually make this important. Thanks!
LukeShu 3y ago
It's to prevent CSRF attacks. The attacker writes their own client and does half of a login on their own end (getting an authorization-code, but not yet exchanging it for an access-token), and then tricks the end-user to navigate to //service/connect-slack-finalize?code=<attackers-code>&state=<whatever>. But with the state parameter, the client can check the state parameter against a session cookie that it set previously, and say "wait a minute, this is the conclusion of a login from a different browser". Depending on what all session-state the client is keeping track of, it may make sense to sign that state-parameter-nonce to avoid having to remember session state server-side; but the simple case would be to just check whether it == a cookie value.

rtpg 3y ago

Using [0] as a reference, I'm talking about Step 3. This is, in my experience, the "normal" way that people are setting up OAuth between 2 services, with a user going through the flow. [1] includes info on this (see "flawed CSRF protection") [0]: https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2#step-3-application-receives-authorization-code https://www.digitalocean.com/community/tutorials/an-introduc... [1] https://portswigger.net/web-security/oauth https://portswigger.net/web-security/oauth

krinchan 3y ago
Aha! That makes sense! Yes that can be a problem. We exclusively use a single (our own) IdP so it's less important for us. But good to know as some future feature work will actually make this important. Thanks!

LukeShu 3y ago

It's to prevent CSRF attacks. The attacker writes their own client and does half of a login on their own end (getting an authorization-code, but not yet exchanging it for an access-token), and then tricks the end-user to navigate to //service/connect-slack-finalize?code=<attackers-code>&state=<whatever>. But with the state parameter, the client can check the state parameter against a session cookie that it set previously, and say "wait a minute, this is the conclusion of a login from a different browser". Depending on what all session-state the client is keeping track of, it may make sense to sign that state-parameter-nonce to avoid having to remember session state server-side; but the simple case would be to just check whether it == a cookie value.