OAuth 偵錯器

Proof Key for Code Exchange（PKCE，RFC 7636）最初是為無法安全儲存用戶端密鑰的行動裝置與原生應用程式所設計。其運作方式是由用戶端產生一組隨機的 code_verifier，再由其衍生出 code_challenge（SHA-256 加 base64url），並在授權請求中傳送此 challenge。在以授權碼交換權杖時，用戶端會傳送原始的 code_verifier。授權伺服器會驗證其與先前的 challenge 是否相符——藉此證明權杖請求確實來自發起此流程的同一個用戶端。

即使是機密用戶端（擁有用戶端密鑰的伺服器端應用程式），OAuth 2.1 現在也建議採用 PKCE，作為防範授權碼攔截攻擊的措施。

隱含式流程（response_type=token）原本是為單頁應用程式設計的捷徑，直接在網址片段中回傳存取權杖。這會造成嚴重問題：網址中的權杖會出現在瀏覽器歷史記錄、伺服器記錄與 referrer 標頭中，且此流程容易受到權杖注入攻擊。OAuth 2.0 安全性最佳實務（RFC 9700）與 OAuth 2.1 已明確移除隱含式流程，改採授權碼流程搭配 PKCE，讓單頁應用程式能在無需用戶端密鑰的情況下安全使用。

• 所有授權碼流程（包括機密用戶端）皆需要 PKCE。
• 移除隱含式流程——請改用授權碼流程搭配 PKCE。
• 移除資源擁有者密碼憑證（ROPC）——password 授權類型已淘汰。
• 公開用戶端需要重新整理權杖輪替——每次使用都必須核發新的重新整理權杖。
• 重新導向網址需精確比對——不得使用樣式比對或萬用字元。

1. 產生 PKCE 配對：建立一組隨機的 code_verifier，並計算 code_challenge = BASE64URL(SHA256(code_verifier))。
2. 重新導向至授權端點：包含 response_type=code、client_id、redirect_uri、scope、state、code_challenge 與 code_challenge_method=S256。
3. 使用者在授權伺服器進行身份驗證並授予同意。
4. 在您的 redirect_uri 接收授權碼，並隨附回傳的 state——請驗證 state 是否與您傳送的一致。
5. 以授權碼交換權杖：向權杖端點發送 POST 請求，帶上 grant_type=authorization_code、code、redirect_uri、client_id 與 code_verifier。
6. 接收存取權杖（以及選用的 id_token 與 refresh_token），並使用它們呼叫 API。