OAuth PKCE 如何保證應用的安全授權？

OAuth 框架定義了多種授權模式以滿足不同的應用場景，例如：

• 授權碼模式（Authorization Code Flow）

• 隱式授權模式（Implicit Flow）【現在接近廢棄】

• 密碼授權模式（Resource Owner Password Credentials Flow）

• 等等

PKCE（Proof Key for Code Exchange）是對現有授權碼模式的加強，能夠有效防禦跨站請求僞造（CSRF）和授權碼攔截攻擊。

要清楚的一點是 PKCE 是可選的 “強化包”：

• 如果客戶端遵循 PKCE 協議與授權服務器通信，那麼授權服務器會切換到加強的授權碼模式，進而執行 PKCE 定義的額外驗證；

• 如果客戶端沒有遵循 PKCE 協議，那麼授權服務器會回退到基本的授權碼模式。

目前，授權服務器兼容以上兩種方式。但可以預想到在不久的將來，PKCE 可能變爲強制執行，畢竟安全越來越重要。

PKCE 的三個核心要素

1. 客戶端（如 Web SinglePageApplication）生成一個由 43 至 128 個規定字符組成的隨機字符串，稱作 code_verifier。

2. 客戶端選擇一種變換方法，稱作 “code_challenge_method”，用於稍後對 code_verifier 進行轉換。目前，它只能爲以下兩者之一：

3. "plain"，即 code_challenge = code_verifier

4. "S256"，採用 SHA256 算法，即 code_challenge = base64(SHA256(code_verifier))。

5. 使用選擇的 “code_challenge_method” 對 code_verifier 進行變換得到的字符串，稱作 code_challenge。

採用 PKCE 的授權碼工作流

A) 客戶端發授權請求 “/authorization” 到授權服務器，並附帶上兩個新的參數 “code_challenge” 和 “code_challenge_method”。

B) 授權服務器返回只能使用一次的授權碼 “code”，同時必須記錄 “code”、“code_challenge” 和 “code_challenge_method” 三者的關聯關係。因爲稍後要進行校驗。授權服務器既可以將這些信息編碼進 “code” 裏，也可以直接存儲在服務器端。

C) 客戶端再次發獲取令牌請求 “/token” 到授權服務器，並附帶上 “code_verifier” 以及 “code”。

D) 授權服務器找到與該 “code” 關聯的 “code_challenge” 和 “code_challenge_method”；使用保存的 “code_challenge_method” 對 客戶端發過來的 “code_verifier” 進行變換，然後與 “code_challenge” 進行比較。若相同則可以正常授權，返回客戶端請求的令牌。

PKCE 的優點

在不使用 PKCE 時，若授權碼 code 被攻擊者截持，那麼攻擊者就可以使用竊取的授權碼 code 去獲得一個合法的令牌 token，然後用 token 執行攻擊行爲。

在使用 PKCE 時，若授權碼 code 被攻擊者截持，那麼攻擊者也無法獲得一個合法的令牌 token，因爲攻擊者還要提供 code_verifier，而 code_verifier 只有客戶端才知道。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/I7cY0TbfbMJvGANPOhJ72A