Skip to main content
Information Security

Return to Question

Tweeted twitter.com/StackSecurity/status/1407624486694891520
Change wording to intended meaning
Source Link
edit approved Jun 23, 2021 at 7:38
StephenGodderidge
edit approved Jun 23, 2021 at 7:38
StephenGodderidge
  • 5
  • 4

PKCE explanation: https://www.oauth.com/oauth2-servers/pkce/

OAuth Flow example: https://developer.okta.com/docs/guides/implement-auth-code-pkce/use-flow/

My question is more specifically: Is there any reason to require state if PKCE is implemented?

state stops CSRF attacks by having the app server verify the state it gave the client is the same as the state the client gives it (after making the first OAuth request)

  1. App Server generates random state for each unique client & gives to client
  2. Client sends state to Auth Server, Auth Server returns with state & code
  3. Client sends state and code to App Server
  4. App Server ensures state in step 1 == state in step 2

However if you did this with CSRFPKCE:

  1. App Server generates random code_challenge for each unique client & gives it to the client (we can ignore the optional hashing for now)
  2. Client gives code_challenge to the Auth Server, Auth Server returns with code
  3. Client sends code to App Server
  4. App Server sends code & code_challenge in step 1 to Auth Server who verifies that code_challenge in step 1 == code_challenge in step 2

It seems like the exact same flow, except you have to store the code_challenge on your server instead of state being stored in either your server or the client's cookies and the end check is done by the Auth Server instead of the App Server.

PKCE explanation: https://www.oauth.com/oauth2-servers/pkce/

OAuth Flow example: https://developer.okta.com/docs/guides/implement-auth-code-pkce/use-flow/

My question is more specifically: Is there any reason to require state if PKCE is implemented?

state stops CSRF attacks by having the app server verify the state it gave the client is the same as the state the client gives it (after making the first OAuth request)

  1. App Server generates random state for each unique client & gives to client
  2. Client sends state to Auth Server, Auth Server returns with state & code
  3. Client sends state and code to App Server
  4. App Server ensures state in step 1 == state in step 2

However if you did this with CSRF:

  1. App Server generates random code_challenge for each unique client & gives it to the client (we can ignore the optional hashing for now)
  2. Client gives code_challenge to the Auth Server, Auth Server returns with code
  3. Client sends code to App Server
  4. App Server sends code & code_challenge in step 1 to Auth Server who verifies that code_challenge in step 1 == code_challenge in step 2

It seems like the exact same flow, except you have to store the code_challenge on your server instead of state being stored in either your server or the client's cookies and the end check is done by the Auth Server instead of the App Server.

PKCE explanation: https://www.oauth.com/oauth2-servers/pkce/

OAuth Flow example: https://developer.okta.com/docs/guides/implement-auth-code-pkce/use-flow/

My question is more specifically: Is there any reason to require state if PKCE is implemented?

state stops CSRF attacks by having the app server verify the state it gave the client is the same as the state the client gives it (after making the first OAuth request)

  1. App Server generates random state for each unique client & gives to client
  2. Client sends state to Auth Server, Auth Server returns with state & code
  3. Client sends state and code to App Server
  4. App Server ensures state in step 1 == state in step 2

However if you did this with PKCE:

  1. App Server generates random code_challenge for each unique client & gives it to the client (we can ignore the optional hashing for now)
  2. Client gives code_challenge to the Auth Server, Auth Server returns with code
  3. Client sends code to App Server
  4. App Server sends code & code_challenge in step 1 to Auth Server who verifies that code_challenge in step 1 == code_challenge in step 2

It seems like the exact same flow, except you have to store the code_challenge on your server instead of state being stored in either your server or the client's cookies and the end check is done by the Auth Server instead of the App Server.

Source Link
Ross Grambo
Ross Grambo
  • 183
  • 1
  • 4

Does PKCE replace state in the Authorization Code OAuth flow?

PKCE explanation: https://www.oauth.com/oauth2-servers/pkce/

OAuth Flow example: https://developer.okta.com/docs/guides/implement-auth-code-pkce/use-flow/

My question is more specifically: Is there any reason to require state if PKCE is implemented?

state stops CSRF attacks by having the app server verify the state it gave the client is the same as the state the client gives it (after making the first OAuth request)

  1. App Server generates random state for each unique client & gives to client
  2. Client sends state to Auth Server, Auth Server returns with state & code
  3. Client sends state and code to App Server
  4. App Server ensures state in step 1 == state in step 2

However if you did this with CSRF:

  1. App Server generates random code_challenge for each unique client & gives it to the client (we can ignore the optional hashing for now)
  2. Client gives code_challenge to the Auth Server, Auth Server returns with code
  3. Client sends code to App Server
  4. App Server sends code & code_challenge in step 1 to Auth Server who verifies that code_challenge in step 1 == code_challenge in step 2

It seems like the exact same flow, except you have to store the code_challenge on your server instead of state being stored in either your server or the client's cookies and the end check is done by the Auth Server instead of the App Server.