Authorization Code with PKCE Flow | PingFederate

Understanding the Authorization Code with PKCE Flow in OAuth 2.0: Technical Details and Usage

As the security landscape evolves, ensuring robust protection for users during authentication and authorization becomes increasingly important. OAuth 2.0 has addressed these needs through various grant types, one of which is the Authorization Code Grant. To further improve its security, especially for public clients like single-page applications (SPAs) and mobile apps, the PKCE (Proof Key for Code Exchange) extension has been introduced. This article will dive into the Authorization Code with PKCE Flow, exploring its technical details and use cases.

What is the Authorization Code Flow?

The Authorization Code Flow is a two-step process used in OAuth 2.0 for securely granting an access token to a client application. This flow is ideal for confidential clients, such as web applications running on a server, where the client secret can be securely stored. However, public clients (like mobile or single-page apps) can't store client secrets securely, leaving the flow vulnerable to certain attacks.

That’s where PKCE (Proof Key for Code Exchange) comes in, making the Authorization Code Flow suitable for public clients by adding an extra layer of security.

What is PKCE?

PKCE (Proof Key for Code Exchange) is an extension of the Authorization Code Flow that was originally created to secure native mobile apps. It prevents a variety of attacks, particularly the authorization code interception attack, where a malicious app could intercept the authorization code before it's exchanged for an access token.

In simple terms, PKCE enhances the security of OAuth by allowing public clients to use the Authorization Code Flow without needing to store a client secret. It achieves this by introducing two additional parameters: a code challenge and a code verifier.

Key Terms in PKCE

• Code Verifier: A high-entropy, cryptographically random string generated by the client.
• Code Challenge: A transformation of the code verifier. It is either the base64-url-encoded SHA-256 hash of the code verifier (recommended) or the code verifier itself (less secure).

How Does the Authorization Code with PKCE Flow Work?

The Authorization Code with PKCE flow follows a similar process to the regular Authorization Code Flow, but with additional steps to ensure better security. Here’s a breakdown of the flow:

1. Client Generates a Code Verifier and Code Challenge

The client starts by generating a random code verifier. This is a cryptographically random string that can be anywhere from 43 to 128 characters long.

The client then hashes the code verifier using SHA-256 (recommended for better security) to generate a code challenge. If hashing is not supported, the code verifier itself can be used as the code challenge.

2. Client Requests Authorization

The client sends the user to the authorization server (e.g., PingFederate), including the following parameters:

• response_type=code: Indicates the Authorization Code Flow.
• client_id: Identifies the client app.
• redirect_uri: The URI where the authorization server will send the authorization code.
• scope: Specifies the access the client is requesting (e.g., openid profile).
• code_challenge: The code challenge generated in the first step.
• code_challenge_method: Specifies the method used for the code challenge (S256 for SHA-256 or plain for using the code verifier directly).

3. User Authentication

The user authenticates with the authorization server, typically by entering their credentials. After authentication, the authorization server redirects the user back to the client’s redirect URI with an authorization code.

4. Client Requests the Access Token

Next, the client sends a POST request to the authorization server's token endpoint to exchange the authorization code for an access token. This request includes:

• grant_type=authorization_code: Specifies the grant type.
• code: The authorization code received from the previous step.
• redirect_uri: The same redirect URI used during the authorization request.
• client_id: The client ID again.
• code_verifier: The original code verifier generated in the first step.

5. Server Verifies and Issues an Access Token

The authorization server verifies that the code verifier matches the code challenge sent earlier. If they match, the server issues an access token (and optionally a refresh token) to the client.

Flow Summary

In summary, the Authorization Code with PKCE flow adds an extra layer of security by ensuring that even if a malicious entity intercepts the authorization code, they cannot use it without the original code verifier. Here’s a visual summary:

1. Client generates: code_verifier and code_challenge
2. Client sends: Authorization request with code_challenge
3. User authenticates: Authorization code returned to the client
4. Client sends: Authorization code and code_verifier
5. Server validates: Code verifier and issues token

Technical Details and Best Practices

Here are some important technical details to keep in mind when implementing Authorization Code with PKCE:

1. Code Verifier Length and Security

The code verifier should be a randomly generated string that is between 43 and 128 characters long. The randomness ensures that it’s difficult to guess or predict, providing enhanced security.

2. Code Challenge Methods

It’s recommended to use the S256 hashing method (SHA-256), which transforms the code verifier into a hashed code challenge. The plain method (using the code verifier directly) is allowed but is less secure.

3. No Client Secret Required

The beauty of PKCE is that it allows public clients (which cannot securely store secrets) to use the Authorization Code Flow. PKCE replaces the need for a client secret, which is why it’s ideal for mobile apps and SPAs.

4. Short Token Expiry

For additional security, the access tokens issued in this flow should be short-lived, with a refresh token provided for renewing the session.

Use Cases for Authorization Code with PKCE

The Authorization Code with PKCE Flow is specifically designed for public clients, but it can also be used by confidential clients. Below are some common use cases:

1. Single-Page Applications (SPAs): SPAs can use PKCE to securely authenticate users without storing sensitive information in the browser.

2. Mobile Apps: Native mobile apps (iOS/Android) benefit from PKCE by securing the token exchange without needing a client secret.

3. Cross-Platform Applications: Any application that runs in environments where a client secret cannot be securely stored should use the PKCE flow to avoid exposing sensitive data.

4. OAuth and OpenID Connect (OIDC): PKCE is widely adopted in OpenID Connect (OIDC), especially for mobile authentication and identity federation scenarios, enhancing security across different platforms.

Security Considerations

Although PKCE provides significant security improvements over the standard Authorization Code Flow, some best practices should be followed:

1. Always Use HTTPS: Ensure that the entire OAuth 2.0 flow occurs over HTTPS to prevent token interception.

2. Use S256 for Code Challenge Method: Prefer the S256 hashing method for the code challenge to maximize security.

3. Short-Lived Access Tokens: Keep access tokens short-lived and use refresh tokens to extend sessions when needed.

4. Regular Token Revocation: Implement token revocation strategies to ensure that old tokens cannot be reused after they expire or when users log out.

Conclusion

The Authorization Code with PKCE Flow provides a secure way to implement OAuth 2.0 for public clients like SPAs and mobile apps, protecting against various attacks that can occur when sensitive information is exposed. By incorporating PKCE, applications benefit from the best of both worlds: the security of the Authorization Code Flow and the flexibility to work in environments where client secrets can't be securely stored.

Whether you’re building a web app, a mobile app, or integrating with PingFederate, the Authorization Code with PKCE Flow ensures that user authorization remains secure and streamlined.

Share on Google Plus

About Satya

Satya is an IAM Engineer and the Editor of Techstotle.com. He possesses a deep passion for Identity and Access Management (IAM) technologies, with a particular focus on PingFederate and PingAM. Satya is dedicated to demystifying these complex technologies and making them accessible to a wider audience. Techstotle.com serves as a one-stop shop for the latest IAM insights, featuring comprehensive tutorials on PingFederate and PingAM. Join Satya on this journey of tech exploration as he empowers you to navigate the ever-evolving world of IAM.