OAuth 偵錯器

Proof Key for Code Exchange (PKCE, RFC 7636) was originally designed for mobile and native apps that cannot securely store a client secret. It works by having the client generate a random code_verifier, derive a code_challenge from it (SHA-256 + base64url), and send the challenge with the authorization request. When exchanging the authorization code for tokens, the client sends the original code_verifier. The authorization server verifies it matches the earlier challenge — proving the token request came from the same client that started the flow.

Even for confidential clients (server-side apps with a client secret), PKCE is now recommended by OAuth 2.1 as a defense against authorization code interception attacks.

The implicit flow (response_type=token) was designed as a shortcut for single-page apps, returning the access token directly in the URL fragment. This creates serious problems: tokens in URLs appear in browser history, server logs, and referrer headers, and the flow is vulnerable to token injection attacks. OAuth 2.0 Security Best Current Practice (RFC 9700) and OAuth 2.1 explicitly remove the implicit flow in favor of Authorization Code + PKCE, which SPAs can use safely without a client secret.

• PKCE required for all Authorization Code flows, including confidential clients.
• Implicit flow removed — use Authorization Code + PKCE instead.
• Resource Owner Password Credentials (ROPC) removed — the password grant type is deprecated.
• Refresh token rotation required for public clients — a new refresh token must be issued with each use.
• Redirect URI exact matching required — no pattern matching or wildcards.

1. Generate PKCE pair: Create a random code_verifier and compute code_challenge = BASE64URL(SHA256(code_verifier)).
2. Redirect to authorization endpoint: Include response_type=code, client_id, redirect_uri, scope, state, code_challenge, and code_challenge_method=S256.
3. User authenticates at the authorization server and grants consent.
4. Receive authorization code at your redirect_uri alongside the echoed state — verify state matches what you sent.
5. Exchange code for tokens: POST to the token endpoint with grant_type=authorization_code, code, redirect_uri, client_id, and code_verifier.
6. Receive access token (and optionally id_token and refresh_token) and use them to call APIs.