Why does the OAuth2.0 Security Best Current Practice draft say all auth grant type implementations should use PKCE?

1
votes

The current best practices draft of OAuth2.0 security topics has the following in section 3.1.1:

"Clients utilizing the authorization grant type MUST use PKCE [RFC7636] in order to (with the help of the authorization server) detect and prevent attempts to inject (replay) authorization codes into the authorization response. ... Note: although PKCE so far was recommended as a mechanism to protect native apps, this advice applies to all kinds of OAuth clients, including web applications."

  • "Clients utilizing the authorization grant type MUST use PKCE ... to detect and prevent attempts to inject (reply) authorization codes into the authorization response."
    • How, exactly, does PKCE help "detect" attempts at replying auth codes? There's nothing in its RFC that suggests it'd handle detection any better than the OAuth2.0 RFC that MUST deny requests if they contain an auth code already used.
    • How, exactly, does PKCE help "prevent" authorization code replay attacks for web apps with a backend handling the auth code request and redirect? I'm operating under the assumption that the auth code request and redirect both happen with TLS. What chance is there (and how does it work) that the auth code can be replayed?

An important thing to note:

"... this advice applies to all kinds of OAuth clients, ..." captures web apps that have a backend component handling the auth code request and access token exchange. So, we're not talking about a web app that might have previously used the implicit grant type; we're talking about web apps that can use the authorization grant type.

1
oauthoauth-2.0rfcpkce

1 Answers

0
votes

Here are the basic steps from RFC 7636.

  1. The client includes a cryptographic secret with the request for an authz code to the authz endpoint
  2. Authz server returns auth code with the secret encrypted in code or stored on auth server
  3. Client sends auth code with the secret to the token endpoint
  4. Authz server verifies secret and responds with token

So the authz server only returns a token if the secret is verified as the one that was sent earlier for the authz code.

As you suggest, this doesn't work better than an OAuth 2.0 implementation that rejects multiple uses of the same authz code. But, it's meant to prevent the use of an authz code that's not associated with the one that was sent earlier and associated with that secret or one that was sent earlier that doesn't have the right secret.

If the backend is handling the communication with the authz server and doing so over TLS, it shouldn't have to worry about the authz code attacks. But the authz code grant type is a redirection based flow. You'd probably be better served using the client credentials grant type. Web app here means one that's acting as the client.