If you use OAuth to authorize your applications to access protected resources, you may have heard of PKCE, or Proof Key for Code Exchange. PKCE is an extension of the authorization code grant that adds an extra layer of security to prevent interception attacks. In this article, you will learn how PKCE works and why you should use it for your OAuth flows.
PKCE is a mechanism that allows the client application to generate a random code verifier and a derived code challenge, and send them to the authorization server along with the authorization request. The code challenge is a hashed and encoded version of the code verifier, which can be verified by the authorization server using the same hashing and encoding method. The authorization server then returns an authorization code to the client, which can be exchanged for an access token at the token endpoint. However, the client must also provide the original code verifier along with the authorization code, and the authorization server must match it with the previously received code challenge. This way, only the client that initiated the authorization request can obtain the access token.
PKCE is a security extension to OAuth 2.0 that mitigates authorization code interception attacks. When I first encountered PKCE, it struck me as a clever yet straightforward solution. It involves the client creating a secret (the Code Verifier) and a transform of it (the Code Challenge) when initiating an authorization request. This way, even if an attacker intercepts the authorization code, they cannot exchange it for a token without the Code Verifier, which is not transmitted until the token exchange request.
PKCE was designed to address a security vulnerability in the authorization code grant, which is the most common and recommended OAuth flow for web and mobile applications. The vulnerability arises when an attacker intercepts the authorization code that is sent from the authorization server to the client via a redirect URI. The attacker can then use the stolen code to request an access token from the token endpoint, impersonating the legitimate client. This is especially risky for public clients, which are applications that cannot store a client secret securely, such as native or single-page applications. PKCE prevents this type of attack by requiring the client to prove its identity with the code verifier, which is not exposed in the redirect URI and cannot be guessed by the attacker.
Initially designed for clients unable to securely store credentials, I found PKCE universally beneficial. Its true value lies in its ability to secure public clients against attacks where the authorization code could be intercepted. By ensuring that only the client that initiated the authorization request can exchange the authorization code for an access token, PKCE significantly reduces the risk of unauthorized access.
In order to implement PKCE, you must generate a random code verifier of 43-128 characters containing A-Z, a-z, 0-9, -, ., _, or ~. Then create a code challenge from the verifier using either the plain or S256 method. After that, include the code challenge and the code challenge method in the authorization request. Once you receive an authorization code from the authorization server, include that code and the code verifier in the token request. Finally, receive an access token from the authorization server and use it to access the protected resource.
Implementing PKCE was an enlightening experience. It starts with generating a high-entropy code verifier and its derived code challenge for each authorization request. During the token exchange, the verifier is sent along with the authorization code. This process was easier than I expected, thanks to libraries and frameworks that abstract much of the complexity. Integrating PKCE into our OAuth 2.0 flow brought a new level of security to our applications with minimal disruption.
PKCE offers several benefits for your OAuth flows, such as enhancing the security of the authorization code grant by mitigating the risk of authorization code interception attacks. It also enables public clients to use the authorization code grant without a client secret, which is more secure than using the implicit grant. PKCE simplifies the integration of native and single-page applications with OAuth providers, as they do not need to register a static redirect URI or use a custom scheme or loopback interface. Additionally, it supports dynamic redirect URIs, which can be useful for scenarios where the client needs to redirect to different locations based on the user's context or preferences.
The benefits of PKCE are manifold. Beyond its primary function of preventing code interception attacks, it also instilled a deeper sense of security in our development practices. It was a game-changer for our public clients, allowing them to achieve a level of security that was previously difficult to attain. The simplicity and effectiveness of PKCE in enhancing the OAuth 2.0 authorization process cannot be overstated.
PKCE is not without its challenges, however. It requires the support of both the client and the authorization server, which may not be available in all OAuth providers or libraries. Additionally, it adds complexity and overhead to the OAuth flow, as you need to generate and store the code verifier and challenge, and include them in the authorization and token requests. It should be noted that PKCE does not protect against other types of attacks such as phishing, malware, or cross-site request forgery. Thus, it is important to follow best practices for securing your OAuth flows such as using HTTPS, validating redirect URIs, checking scopes, and implementing state parameters.
While PKCE is relatively straightforward to implement, understanding its mechanics and ensuring proper integration can be challenging for those new to OAuth 2.0. Ensuring that every client and authorization server supports PKCE was initially a hurdle. There's also the matter of keeping the code verifier secure on the client side, which requires careful consideration, especially in less secure environments.
Here’s What Else to Consider: Standard Adoption: With the evolution of OAuth to version 2.1, PKCE is becoming a standard part of the OAuth flow. It was originally designed for the use with public clients, but can be used for all OAuth authorization code grants independent of the client type. Educational Effort: There's a need to educate developers about the importance and mechanics of PKCE to encourage its widespread and correct implementation. Continuous Evaluation: As with any security measure, it’s important to continually evaluate PKCE against emerging threats and adapt as necessary.
Best practice: - Use with Authorization Code Flow. - Generate high-entropy code verifier. - Derive a strong code challenge using a secure hashing algorithm. - Ensure all communications are over HTTPS. - Rotate code verifiers for each authorization request. - Implement proper error handling to avoid leaking sensitive information. - Include the code verifier in the token exchange process for additional security. - Set appropriate expiration times for access and refresh tokens. - Implement rate limiting and throttling to mitigate abuse or brute-force attempts. - Safely store and handle tokens on the client side using secure mechanisms. - Conduct regular security audits to identify and address vulnerabilities. - Use third-party for reliability.
As recommended by RFC7636, the client should consider create a code verifier with a minimum of 256 bits of entropy. This can be done by having a suitable random number generator create a 32-octet sequence. The octet sequence can then be base64url-encoded to produce a 43-octet URL safe string to use as a code challenge that has the required entropy.
Adopting PKCE is not just about following a security best practice; it's about embracing a security-first mindset. While PKCE significantly enhances security, it's also crucial to stay informed about emerging threats and continuously assess and update security measures in your OAuth 2.0 implementations. My experience has taught me that security is a journey, not a destination, and PKCE is a valuable step on that journey.