Hello everyone, I think RFC 7636 "Proof Key for Code Exchange by OAuth Public Clients", section 4.6. "Server Verifies code_verifier before Returning the Tokens" leaves a tiny gap regarding the handling of verification when no code challenge was present in the authorization request: Upon receipt of the request at the token endpoint, the server verifies it by calculating the code challenge from the received "code_verifier" and comparing it with the previously associated "code_challenge", after first transforming it according to the "code_challenge_method" method specified by the client. It is unspecified how the server should behave when "code_verifier" is present, but "code_challenge" and "code_challenge_method" were not set in the initial authorization request. The following example worked for three well-known authorization servers where the client was configured in a way that PKCE could be used, but was not enforced: Authorization Request: https://XXXX/auth?client_id=YYYY&response_type=code&scope=openid+profile&redirect_uri=https://localhost Subsequent Token Request: POST /token HTTP/1.1 Host: XXXX Content-Length: 256
code=ZZZZ&grant_type=authorization_code&client_id=YYYY&redirect_uri=https%3A%2F%2Flocalhost&code_verifier=IqiCQGM06JEyW73AB3f3oblCQKHOorapyqHUcYRujuSikDJx8cvBQ0kmFmzW75uIfaSBtXQrRmwuk71WWO6ryCzahTcxBPYX As a result, an access token was issued although the code_verifier provided in the token request did not match the code_challenge and code_challenge_method in the authorization request. Many applications consider the usage of PKCE as enough protection from Login-CSRF and do not use state or nonce (for example this blog entry by Daniel Fett https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/ suggests, that neither state nor nonce are necessary when PKCE is used). However, when the authorization server is not configured to require a specific code_challenge_method from the client and the authorization behaves as described in the example, PKCE does not protect from Login-CSRF. I think the following mitigations are possible: * Enforce usage of PKCE in the client configuration in the Authorization Server * Implementation of the authorization server returns an error in the Access Token Response when code_verifier is present in the token request, but no code_challenge and code_challenge_method is present in the authorization request. * Additionally, when the behavior of an AS is correct (verification of code_verifier fails when no code_challenge was present), a client that relies on PKCE for CSRF protection must always include a code_verifier parameter in the token request (even if no code_verifier is present on the client side). Best regards, Benjamin Häublein Senior Consultant cirosec GmbH Ferdinand-Braun-Strasse 4 74074 Heilbronn Germany Phone: +49 (7131) 59455-74 Fax: +49 (7131) 59455-99 Mobile: +49 (151) 122414-74 www.cirosec.de HRB Stuttgart 107883 CEO Stefan Strobel, CFO Peter Lips
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
