PKCE (Proof Key for Code Exchange)
PKCE (Proof Key for Code Exchange) 是什么?
PKCE (Proof Key for Code Exchange)An OAuth 2.0 extension (RFC 7636) that binds an authorization-code redemption to a one-time secret created by the client, neutralizing authorization-code interception attacks on public and confidential clients alike.
PKCE (Proof Key for Code Exchange, RFC 7636) is an OAuth 2.0 extension originally introduced to protect public clients — mobile apps, single-page apps, native CLIs — from authorization-code interception attacks, and now recommended for every OAuth 2.0 client by the OAuth 2.1 BCPs. The flow adds two parameters. At the authorization request, the client generates a high-entropy `code_verifier`, hashes it (SHA-256) into a `code_challenge`, and sends the challenge to the authorization server. When the client later exchanges the returned authorization code for tokens, it sends the original `code_verifier`; the server hashes it and rejects the exchange unless the result matches the challenge it remembered. Because the verifier never leaves the client until the token exchange, an attacker who intercepts the redirect URL (via a registered scheme on a malicious app, a referrer leak, or a misconfigured intermediate) cannot redeem the code. Modern guidance (OAuth 2.1, FAPI, Entra ID, Auth0, Okta) recommends PKCE for confidential clients too, and many IdPs now enforce it.
● 示例
- 01
A React SPA initiates the OAuth code flow with a SHA-256 `code_challenge`, then exchanges the returned code plus `code_verifier` for tokens from the IdP.
- 02
An IdP rejects an authorization-code grant from a public client that arrived without a matching PKCE verifier, treating it as a sign of interception.
● 常见问题
PKCE (Proof Key for Code Exchange) 是什么?
An OAuth 2.0 extension (RFC 7636) that binds an authorization-code redemption to a one-time secret created by the client, neutralizing authorization-code interception attacks on public and confidential clients alike. 它属于网络安全的 身份与访问 分类。
PKCE (Proof Key for Code Exchange) 是什么意思?
An OAuth 2.0 extension (RFC 7636) that binds an authorization-code redemption to a one-time secret created by the client, neutralizing authorization-code interception attacks on public and confidential clients alike.
PKCE (Proof Key for Code Exchange) 是如何工作的?
PKCE (Proof Key for Code Exchange, RFC 7636) is an OAuth 2.0 extension originally introduced to protect public clients — mobile apps, single-page apps, native CLIs — from authorization-code interception attacks, and now recommended for every OAuth 2.0 client by the OAuth 2.1 BCPs. The flow adds two parameters. At the authorization request, the client generates a high-entropy `code_verifier`, hashes it (SHA-256) into a `code_challenge`, and sends the challenge to the authorization server. When the client later exchanges the returned authorization code for tokens, it sends the original `code_verifier`; the server hashes it and rejects the exchange unless the result matches the challenge it remembered. Because the verifier never leaves the client until the token exchange, an attacker who intercepts the redirect URL (via a registered scheme on a malicious app, a referrer leak, or a misconfigured intermediate) cannot redeem the code. Modern guidance (OAuth 2.1, FAPI, Entra ID, Auth0, Okta) recommends PKCE for confidential clients too, and many IdPs now enforce it.
如何防御 PKCE (Proof Key for Code Exchange)?
针对 PKCE (Proof Key for Code Exchange) 的防御通常结合技术控制与运营实践,详见上方完整定义。
PKCE (Proof Key for Code Exchange) 还有哪些其他名称?
常见的别称包括: RFC 7636, Proof Key for Code Exchange。
● 相关术语
- identity-access№ 839
OAuth 2.0
开放的授权框架,允许资源所有者在不共享凭据的情况下,授予第三方应用对 API 的有限范围访问。
- identity-access№ 852
OpenID Connect (OIDC)
构建在 OAuth 2.0 之上的身份层,允许客户端通过签名的 ID 令牌验证用户身份并获取基本资料。
- identity-access№ 090
授权
在身份认证完成后,决定该身份对哪些资源、可以执行哪些操作以及在何种条件下被允许的过程。
- identity-access№ 642
JWT(JSON Web Token)
紧凑、URL 安全的令牌格式(RFC 7519),携带带签名的 JSON 声明,广泛用作访问令牌、ID 令牌和会话载体。
- identity-access№ 089
身份认证
在授予访问权限前,验证某个实体(用户、设备或服务)确实是其所声称身份的过程。
- identity-access№ 395
DPoP (Demonstrating Proof of Possession)
An OAuth 2.0 extension (RFC 9449) that binds access tokens to a per-client key pair, so a stolen bearer token cannot be replayed by an attacker without also stealing the private signing key.