Proof Key for Code Exchange

Description

Proof Key for Code Exchange (PKCE, pronounced 'pixie') is defined in 3GPP TS 33.180 as a security enhancement for the OAuth 2.0 framework, specifically for the authorization code grant type. It is primarily intended to secure public clients—applications that cannot securely store a client secret, such as native mobile apps or single-page web applications. The core mechanism involves the client creating a cryptographically random string called a 'code verifier' and its transformed value, the 'code challenge', which are used to bind the authorization request to the subsequent token request.

Architecturally, PKCE introduces two new parameters to the OAuth flow. At the start of the authorization process, the client generates a high-entropy cryptographically random string, the code verifier. It then creates a code challenge by applying a transformation (like SHA-256) to the verifier. This code challenge is sent to the authorization server along with the standard authorization request. The authorization server associates this challenge with the issued authorization code and stores it.

When the client later exchanges the received authorization code for an access token, it must present the original code verifier in the token request. The authorization server recalculates the code challenge from the submitted verifier and compares it to the stored challenge associated with the authorization code. A match proves that the entity requesting the token is the same one that initiated the authorization request, mitigating the risk of an intercepted authorization code being used by a malicious actor. This process does not require a client secret, making it ideal for applications executing in an insecure environment. Its role in the 3GPP ecosystem is crucial for securing network API access for third-party applications, ensuring that authentication and authorization for services like location or payment APIs are robust against attack.

Purpose & Motivation

PKCE was created to address a critical vulnerability in the standard OAuth 2.0 authorization code flow when used by public clients. The traditional flow assumes the client can authenticate itself with a secret, but this is impractical and insecure for applications running on a user's device where secrets can be easily extracted. Without PKCE, an attacker could intercept the authorization code (e.g., through a malicious app on the same device or by manipulating redirect URIs) and use it to obtain an access token, impersonating the legitimate client.

The historical context is the growing reliance on OAuth for mobile and web application authentication. 3GPP adopted PKCE (originally an IETF RFC 7636 extension) to secure the Network APIs exposed by service providers. It solves the problem of authorization code injection and interception attacks by introducing a proof-of-possession mechanism. The client proves it initiated the original request, closing a significant security gap. This was motivated by the need for a standardized, robust security protocol for third-party applications accessing telecom network functions, ensuring user data and network resources are protected even when the client application itself cannot be fully trusted with a long-term secret.