PricingLoginStart free
OAuth2 & OpenID Connect Deep Dive · 课时

面向公共客户端的 PKCE

了解代码交换证明密钥（PKCE），以及它如何保护公共客户端（例如移动应用）免受授权码拦截攻击。

第 1 / 4 课12 个步骤

面向公共客户端的 PKCE 是 CoddyKit 上的免费 OAuth2 & OpenID Connect Deep Dive 课时。 这是第 1 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 OAuth2 & OpenID Connect Deep Dive 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 OAuth2 & OpenID Connect Deep Dive 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

Public Clients & No Secrets

Imagine a mobile app or a Single-Page Application (SPA) running in a browser. These are known as public clients in OAuth2.

  • They run on devices or environments that can't reliably keep a secret.
  • Unlike a server-side application, they can't securely store a client secret.

This lack of a secret creates a security challenge, making them vulnerable to certain attacks.

Authorization Code Interception

Without a client secret, public clients face a specific risk: the Authorization Code Interception Attack.

  • An attacker might intercept the authorization code sent back to your app.
  • If they get the code, and there's no client secret to verify, they could exchange it for an access token.

This means an attacker could gain access to a user's resources, impersonating your application.

PKCE: Protecting Public Clients

To protect public clients from interception attacks, OAuth2 introduced Proof Key for Code Exchange (PKCE), pronounced "pixy."

  • PKCE adds a dynamic secret to the authorization code flow.
  • This secret is created by the client for each authorization request.

Even if an attacker intercepts the authorization code, they won't have this secret, preventing them from exchanging the code for tokens.

Code Verifier: The Client's Secret

At the heart of PKCE is the code_verifier. It's a cryptographically random string generated by the client application for each authorization attempt.

  • It's a high-entropy secret, meaning it's long and hard to guess.
  • The client keeps this code_verifier private and never sends it directly to the authorization endpoint.

Think of it as a one-time password your app generates and remembers.

Code Challenge: The Public Proof

Instead of sending the code_verifier, the client sends a code_challenge to the authorization server.

  • The code_challenge is a transformed version of the code_verifier.
  • The transformation method (e.g., SHA256 hash then Base64Url encode) is specified by code_challenge_method.

This allows the authorization server to verify the client later without ever knowing the actual code_verifier upfront.

PKCE Flow: Auth Request

Let's trace the PKCE flow. First, the public client (your app) prepares for authorization:

  1. It generates a unique code_verifier.
  2. It transforms this into a code_challenge using S256 (SHA256 hash + Base64Url encoding).
  3. It then sends an authorization request to the Authorization Server, including the code_challenge and code_challenge_method.

Example parameters: code_challenge=xyz&code_challenge_method=S256

PKCE Flow: Auth Code Grant

Upon receiving the authorization request with the code_challenge:

  1. The Authorization Server stores the received code_challenge and its method.
  2. It authenticates the user and obtains their consent.
  3. It then redirects the user back to the client's registered redirect URI, providing an authorization code.

At this point, the client still holds its code_verifier locally.

PKCE Flow: Token Request

Now, with the authorization code in hand, the client needs to exchange it for an access token:

  1. The client makes a POST request to the Authorization Server's token endpoint.
  2. This request includes the authorization code AND the original code_verifier it generated earlier.

This is where the magic happens! The code_verifier acts as proof that this client is the legitimate one.

PKCE Flow: Verification & Tokens

When the Authorization Server receives the token request with the code_verifier:

  1. It recalculates the code_challenge using the provided code_verifier and the stored code_challenge_method.
  2. It compares this newly calculated challenge with the code_challenge it stored in Step 1.
  3. If they match, the client is verified, and the Authorization Server issues access and refresh tokens. Otherwise, the request is denied.

Generating Verifier & Challenge

Here's a simple Java example demonstrating how to generate a code_verifier and its corresponding code_challenge using the S256 method. This is a core part of PKCE implementation.

Try running the code to see the generated values!

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.security.SecureRandom;
import java.util.Base64;

public class Main {

    public static void main(String[] args) throws NoSuchAlgorithmException {
        // 1. Generate a secure random code_verifier
        SecureRandom sr = new SecureRandom();
        byte[] codeVerifierBytes = new byte[32]; // 32 bytes = 256 bits
        sr.nextBytes(codeVerifierBytes);
        String codeVerifier = Base64.getUrlEncoder().withoutPadding().encodeToString(codeVerifierBytes);

        // 2. Derive the code_challenge using S256 (SHA256 + Base64Url-encode)
        MessageDigest md = MessageDigest.getInstance("SHA-256");
        byte[] digest = md.digest(codeVerifier.getBytes(java.nio.charset.StandardCharsets.US_ASCII));
        String codeChallenge = Base64.getUrlEncoder().withoutPadding().encodeToString(digest);

        System.out.println("Code Verifier: " + codeVerifier);
        System.out.println("Code Challenge: " + codeChallenge);
        System.out.println("Method: S256");
    }
}

PKCE Quick Check

PKCE adds a vital layer of security for public clients. Which of the following best describes the primary problem PKCE solves?

在交互式课程中回答

Recap: PKCE's Security Layer

We've learned about PKCE, a crucial security extension for OAuth2, especially for public clients like mobile apps and SPAs.

  • Public clients can't securely store client secrets.
  • PKCE uses a one-time code_verifier and its transformed code_challenge to verify the legitimate client.
  • This protects against Authorization Code Interception attacks, ensuring only the intended client can exchange the authorization code for tokens.

PKCE makes OAuth2 flows much more secure for applications that operate in less trusted environments.

免费开始

用 AI 导师学习 OAuth2 & OpenID Connect Deep Dive — 免费

在浏览器中编写并运行真实代码，获得全天候 AI 导师的即时帮助，并在网页或应用中继续学习。

课程
12
课程
48
免费开始学习查看完整课程

常见问题解答

「面向公共客户端的 PKCE」课时是免费的吗？

是的 — 「面向公共客户端的 PKCE」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 OAuth2 & OpenID Connect Deep Dive 课程的其余内容，请升级到 CoddyKit PRO。 OAuth2 & OpenID Connect Deep Dive 课程共包含 4 节课。

「面向公共客户端的 PKCE」这节课中我会学到什么？

了解代码交换证明密钥（PKCE），以及它如何保护公共客户端（例如移动应用）免受授权码拦截攻击。 你通过在浏览器中直接运行的动手代码来练习 OAuth2 & OpenID Connect Deep Dive，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 OAuth2 & OpenID Connect Deep Dive 需要有经验吗？

无需任何先前经验。CoddyKit 上的 OAuth2 & OpenID Connect Deep Dive 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。 这是第 1 节课，共 4 节。

「面向公共客户端的 PKCE」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 OAuth2 & OpenID Connect Deep Dive 课中编写并运行代码吗？

能。每节 OAuth2 & OpenID Connect Deep Dive 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

  1. 面向公共客户端的 PKCE
  2. 刷新令牌与作用域
  3. 资源所有者密码凭据
  4. 令牌交换（RFC 8693）
← 返回 OAuth2 & OpenID Connect Deep Dive