OAuth 2.0 解決的是『某個 Client 可以代表 Resource Owner 存取哪些資源』，OpenID Connect 才在 OAuth 之上加入可驗證的登入身分。兩者把 Browser、Client、Authorization Server、Resource Server 與多種 Token 分成不同信任邊界；只要把 ID Token 當 API Access Token、Redirect URI 比對過寬、PKCE 可降級、Refresh Token 不輪替，或 API 只驗 JWT 簽章不驗 Issuer、Audience 與 Scope，就可能形成帳號綁定錯誤、授權碼竊取、Token 重播與跨服務權限擴張。本文依 RFC 9700、OpenID Connect Core、RFC 7636、PAR 與 DPoP 規格，建立可實作與驗收的完整安全基線。
先講結論：OAuth 不是登入協定，OIDC 也不是把 JWT 驗過就完成
OAuth 2.0 是授權框架：Resource Owner 允許 Client 在限定範圍內使用 Access Token 存取 Resource Server。它不定義使用者身分斷言的語意；若產品要實作『使用某身分供應商登入』，應採 OpenID Connect，並正確驗證 ID Token、nonce、Issuer、Audience 與登入 Session。
一個安全流程需要同時保護 Redirect-based Front Channel、Client 與 Authorization Server 之間的 Back Channel、Token 儲存、API 驗證、Refresh、撤銷與 Session。任何一段把 Token 放進 URL、允許寬鬆 Redirect、接受錯誤 Audience、共用 Client Secret 或在 Browser 長期保存 Refresh Token，都可能破壞其他控制。
RFC 9700 已將過去常見但不安全的做法明確淘汰或限制：Public Client 必須使用 PKCE，Confidential Client 也建議使用；Implicit Grant 不應使用；Resource Owner Password Credentials Grant 不得使用；Refresh Token 對 Public Client 必須 Sender-constrained 或 Rotation。
- 登入用 OIDC，API 委派授權用 OAuth；先把目標分清楚
- 預設 Authorization Code Flow + PKCE S256，拒絕降級
- Redirect URI 精確比對，不支援任意 Wildcard 或 Open Redirect
- Access、ID、Refresh Token 依用途、Audience、保存位置與生命週期分離
- API 端自己驗證 Issuer、Audience、Scope、Expiry 與必要的 Sender Constraint
先認識五個角色與三條信任邊界
Resource Owner 通常是終端使用者；Client 是請求授權的應用；Authorization Server 負責認證、同意與發 Token；Resource Server 是受 Access Token 保護的 API；User Agent 則承載 Browser Redirect。Client 不是使用者，Authorization Server 也不一定和 Resource Server 位於同一產品。
Front Channel 經過瀏覽器，資料可能出現在 URL、History、Referer、Extension、第三方 Script 與畫面；Back Channel 是 Client Backend 與 Token Endpoint 的直接連線，適合交換 Code 與 Token；Resource Channel 則是 Client 攜 Access Token 呼叫 API。三者威脅與可使用的 Secret 能力不同。
Public Client 如 SPA、Mobile、Desktop 無法可靠保護部署在使用者裝置的 Client Secret；Confidential Client 如受控 Server Backend 可保存 Credential 並進行 Client Authentication。把固定 Secret 打包進 JavaScript 或 App Binary 不會讓 Public Client 變成 Confidential。
| 角色 | 持有或處理 | 核心責任 | 常見錯誤 |
|---|---|---|---|
| Resource Owner | 同意與業務資源 | 理解授權範圍、撤銷授權 | 同意畫面模糊或過度授權 |
| Client | Code、Token、Session、PKCE Verifier | 綁定交易、保護 Token、正確 Callback | 把 ID Token 當 Access Token |
| Authorization Server | 登入、Grant、Key、Code、Refresh Token | 精確驗證、最小授權、輪替與撤銷 | 允許寬鬆 Redirect／PKCE 降級 |
| Resource Server | Access Token 與受保護資料 | 驗證 Issuer、Audience、Scope、Expiry | 只驗簽章或只解碼 JWT |
| User Agent | Redirect、Cookie、Front-channel 資料 | 隔離 Session 與 Origin | Token 進 URL、History 或第三方 Script |
OAuth 2.0、OpenID Connect、SAML 與 JWT 不要混為一談
OAuth 定義委派授權；OIDC 在 OAuth Authorization Code 等流程上增加 ID Token、UserInfo、Discovery、Claims 與登入 Session 語意；SAML 是另一套常見 Federation 協定；JWT 只是可承載 Claims 並簽章的 Token 格式，不等於 OAuth、OIDC 或登入。
Access Token 可以是 JWT，也可以是 Opaque Token；ID Token 通常是 JWT，但它的 Audience 是 Client，不是任意 API；Refresh Token 多半應視為不透明的高價值 Credential。看到三段 Base64URL 並不能推導它可以用在哪裡。
若 Client 只需要登入，不要要求不必要 API Scope；若只需要 API 委派，不要用 ID Token 取代授權決策。Resource Server 的業務物件權限仍要由自身授權邏輯檢查，Scope 不會自動阻止 BOLA／IDOR。
| 概念 | 主要用途 | 主要接收方 | 不能代表 |
|---|---|---|---|
| OAuth 2.0 | 委派 API 存取 | Client、Authorization／Resource Server | 使用者一定已登入或身分可信 |
| OpenID Connect | 在 OAuth 上建立登入與身分 Claims | Relying Party／Client | 任意 API 授權 |
| Access Token | 授權特定 API、資源與動作 | Resource Server | 使用者登入 Session 的全部語意 |
| ID Token | 向 Client 表達 Authentication Event 與身分 | 發起流程的 Client | 呼叫 API 的 Bearer Credential |
| Refresh Token | 向 Authorization Server 取得新 Token | 原始 Client 與 Token Endpoint | 直接存取 Resource Server |
| JWT | Claims 的可簽章封裝格式 | 依 Token Profile 而定 | OAuth／OIDC 本身 |
Authorization Code Flow + PKCE：現代互動式 Client 的預設流程
Client 先為每次交易產生高熵 code_verifier，再以 S256 計算 code_challenge，連同 state、Redirect URI、Client ID、Scope 與必要 OIDC nonce 導向 Authorization Endpoint。Authorization Server 完成登入與同意後，只把短效、單次 Authorization Code 經精確 Callback 回給 Client。
Client 在 Token Endpoint 以 Code、相同 Redirect URI 與原始 code_verifier 交換 Token；Authorization Server 比對其雜湊是否等於先前 Challenge。截獲 Code 的攻擊者沒有 Verifier 就不能交換；但 PKCE 不是 Client Authentication，也不會自動保護錯誤 Redirect、惡意 App Link、Token 儲存或 API 驗證。
RFC 9700 要求 Authorization Server 支援 PKCE；Public Client 必須使用，Confidential Client 也建議使用。S256 是目前不會在 Authorization Request 暴露 Verifier 的方法。若起始請求有 Challenge，Token Endpoint 必須要求正確 Verifier；若 Token Request 突然帶 Verifier，但原請求沒有 Challenge，也必須拒絕，避免 Downgrade。
| 訊息／值 | 產生方 | 綁定對象 | 安全要求 |
|---|---|---|---|
| state | Client | User Agent Session 與授權交易 | 高熵、一次性、比對後失效 |
| nonce | OIDC Client | Authentication Request 與 ID Token | 交易專屬、驗證 Claim、防重播 |
| code_verifier | Client | 單一 Code Exchange | 高熵、留在 Client、不得進 Front Channel |
| code_challenge | 由 Verifier 以 S256 計算 | Authorization Request | Server 保存並在 Token Endpoint 強制比對 |
| Authorization Code | Authorization Server | Client、Redirect URI、交易與 PKCE | 短效、單次、不可記錄 |
state、nonce 與 PKCE 各自解決什麼？不能只留一個隨機字串
state 主要把 Authorization Response 綁回發起流程的 User Agent Session，防止 Login CSRF／授權回應注入，並可安全關聯應用狀態；nonce 在 OIDC 中進入 ID Token，讓 Client 將 Authentication Response 綁定請求並防重播；PKCE 則把 Authorization Code 綁到發起 Client 實例持有的 Verifier。
三者有重疊但不完全相同的安全性。RFC 9700 允許已確認 Authorization Server 正確支援並強制 PKCE 的 Client 依條件使用其 CSRF 保護，OIDC nonce 也能提供相應保護；但工程上仍要依 Client、SDK、多 Issuer、Session 與回應模式決定，不應因為有 PKCE 就刪掉所有 state 管理。
所有值必須交易專屬、不可預測、和發起 Browser Session 安全綁定、驗證後失效。把固定 nonce、固定 code_verifier 或只以 Timestamp 當 state，會讓流程失去關聯與重播防護。state 若承載 Return URL 等資料，還要保護完整性並限制目的地，避免形成 Open Redirect。
| 控制 | 主要防護 | 在哪裡驗證 | 不能取代 |
|---|---|---|---|
| state | CSRF、錯誤交易關聯 | Client Callback | Code 竊取防護、Token 驗證 |
| nonce | OIDC ID Token 重播與回應綁定 | Client 驗 ID Token | Redirect URI 精確比對 |
| PKCE | Authorization Code 攔截、注入與部分 CSRF | Token Endpoint 驗 Verifier | Client Authentication、API Audience／Scope |
| Issuer 驗證 | Mix-Up 與錯誤 Authorization Server | Client Callback／Token 驗證 | state、nonce、PKCE |
Redirect URI 必須精確比對：Wildcard 與 Open Redirect 會把 Code 交給攻擊者
Authorization Server 必須把實際 redirect_uri 與 Client 預先註冊值做精確字串比對；RFC 9700 只對 Native App 的 localhost Port 有特定例外。允許任意子網域、Path Prefix、Query Wildcard 或 Pattern 容易讓攻擊者找出可控制的 Callback、Subdomain Takeover 或 Open Redirect，接收 Code／Token。
Client 與 Authorization Server 都不得提供可由 Query 指定任意目的地的 Open Redirect。Callback 收到 Response 後應立即完成驗證並跳轉到清理過、不含 Code 的內部位置，設定 Referrer-Policy，避免 Code 進入第三方資源、History、Analytics、Error Tracking 或 Access Log。
Native App 應採系統驗證的 Claimed HTTPS URI、Universal Link／App Link，或 RFC 8252 指定的 Loopback Redirect；自訂 URI Scheme 需防止其他 App Claim 同一 Scheme。不要在 Mobile App 內嵌 WebView 收集 Authorization Server 帳密。
- 每個環境、Client 與平台分開註冊 Callback，不以一個 Wildcard 共用
- 註冊、更新 Redirect URI 視為高風險 Client Metadata 變更並稽核
- Callback 不載入第三方 Script、Pixel、字型或不必要資源
- 驗證後使用 303／清潔 URL，Code 與 Error Detail 不留在 History
- Return URL 只允許站內相對路徑或精確 Allowlist
ID Token 要怎麼驗？驗簽章只是第一步
OIDC Client 應從受信 Discovery Metadata 取得 Issuer、Authorization／Token Endpoint 與 JWKS URI，驗證 ID Token 簽章與允許的演算法，再精確比對 iss、aud；若多個 Audience，還要依規格檢查 azp。exp、iat、必要時 auth_time、nonce、acr／amr 也要依流程政策驗證。
Key Selection 必須防止攻擊者控制 jku、x5u 或任意遠端 Key URL。JWKS 來源綁定可信 Issuer，Cache 要有上限、刷新與舊 Key 過渡策略；遇到未知 kid 不應無限向外抓取造成 SSRF 或 DoS。不能接受 alg=none，也不能混用對稱與非對稱演算法造成 Key Confusion。
sub 是 Issuer 內穩定識別使用者的核心 Claim；Email 可能變更、回收、大小寫處理不同，且 email_verified 也不等於可跨 Issuer 唯一識別。資料庫帳號連結應以 Issuer + Subject 建立，而不是只用 Email 自動合併。
| 檢查 | 目的 | 失敗時處置 |
|---|---|---|
| Signature／alg／kid | 確認來自受信 Issuer Key 且演算法允許 | 拒絕，不自動嘗試其他演算法 |
| iss | 確認身分供應者 | 拒絕並防 Mix-Up |
| aud／azp | 確認 Token 是發給此 Client | 拒絕跨 Client 重用 |
| exp／iat／nbf | 確認時間窗口 | 拒絕過期或不合理 Token |
| nonce | 綁定發起的 OIDC 交易 | 拒絕重播或錯誤 Session |
| sub + iss | 建立正確帳號主鍵 | 不以 Email 自動合併 |
| auth_time／acr／amr | 確認驗證新鮮度與方法 | 必要時觸發 reauthentication／Step-up |
Access Token 驗證：Issuer、Audience、Scope、Expiry 缺一不可
Resource Server 不應因為 JWT 簽章有效就接受。它必須確認 Token 來自指定 Issuer、Audience 包含自己、未過期、尚未失效，且 Scope／Authorization Details 足以執行當下 Route、Method、Object 與 Action。相同 Authorization Server 發出的 Token 也可能屬於完全不同 API。
JWT Access Token 應依明確 Profile 驗證；Opaque Token 則可透過受保護的 Introspection Endpoint 取得 Active、Scope、Client、Subject 與 Audience。不能只在 API Gateway 驗一次後，讓內部服務無條件信任可由 Client 偽造的 Header。跨服務傳遞需重新建立可信身分脈絡或 Token Exchange 政策。
Scope 是粗粒度 Delegation，不等於物件層授權。即使 Token 有 orders:read，API 仍須確認這個 Subject／Client 是否能讀取特定 Order、Tenant、欄位與狀態。這也是 OAuth 正確但仍可能發生 BOLA／IDOR 的原因。
| Gate | 必須確認 | 常見錯誤 |
|---|---|---|
| 格式與簽章／Introspection | Token 真實且 Active | 只 Base64 Decode、不驗簽章 |
| Issuer | 只接受明確信任的 Authorization Server | 接受任何能找到 JWKS 的 Issuer |
| Audience／Resource | Token 專屬此 API | 一個 Token 通吃所有微服務 |
| Expiry／Not Before | 目前位於有效時間 | 忽略 exp 或過大 Clock Skew |
| Scope／Authorization Details | 可執行 Route 與 Action | 只在 UI 隱藏按鈕 |
| Subject／Client／Tenant | 具物件與租戶權限 | 有 Scope 就跳過 BOLA 檢查 |
| Sender Constraint | 持有綁定的 mTLS／DPoP Key | 把 Proof-of-possession Token 當 Bearer |
Access、ID、Refresh Token 的保存位置與生命週期要分開
Access Token 通常短效，洩漏後可直接呼叫目標 API；ID Token 提供 Client 建立登入 Session 所需的 Authentication Claims，不應當作 API Credential；Refresh Token 能持續取得新 Token，價值通常最高，應限制 Client、Rotation、閒置與最長壽命。
Server-side Web App 或 Backend-for-Frontend 可把 OAuth Token 保留在受保護 Server，Browser 只持 HttpOnly、Secure、適當 SameSite 的 Session Cookie。這能減少 XSS 直接讀取 Token，但 BFF 仍是高價值邊界，需防 CSRF、Session Fixation、SSRF 與 Server-side Token 外洩。
若 SPA 必須直接持 Access Token，優先記憶體保存與短生命週期，避免 Local Storage／Session Storage 的持久 Bearer Token；第三方 Script、Browser Extension 與 XSS 都可能取得同一 Origin 的敏感資料。Mobile Token 應存於平台 Secure Storage，並處理備份、Root／Jailbreak、裝置遺失與 App Link。
| Token | 接收方 | 典型生命週期 | 保存原則 |
|---|---|---|---|
| Authorization Code | Client Token Exchange | 極短、單次 | 不持久化、不記錄、用後即失效 |
| Access Token | 指定 Resource Server | 短效 | 最小暴露、Audience／Scope 限制 |
| ID Token | 發起 OIDC 的 Client | 登入建立時短效 | 驗證後建立本地 Session，不送任意 API |
| Refresh Token | 原始 Client 與 Token Endpoint | 較長但有限 | Rotation／Sender Constraint、加密保存、可撤銷 |
| Browser Session Cookie | 同站 Web Backend | Idle + Absolute Timeout | HttpOnly、Secure、SameSite、輪替 |
Refresh Token Rotation、Reuse Detection 與 Token Family
Public Client 無法用固定 Secret 證明自己，因此 RFC 9700 要求 Refresh Token 使用 Sender Constraint 或 Rotation。Rotation 每次成功 Refresh 都發新 Token 並使舊 Token 失效；若舊 Token 再出現，代表合法 Client 與攻擊者至少一方持有副本，Authorization Server 應撤銷整個 Token Family 或 Grant 並要求重新授權。
實作要處理網路重試與並行請求，避免合法 Client 因 Race Condition 被誤判。可設計極短 Grace／Idempotency，但不能讓舊 Token 長時間可重用。Family ID、Parent、Issued／Used／Revoked 時間與 Client／Device 脈絡應可稽核，但 Log 不含完整 Token。
Refresh Token 還需要 Idle Timeout、Absolute Lifetime、Scope／Audience 繼承限制、使用者登出與密碼／MFA 事件撤銷。撤銷 Access Token 因為短效或分散式驗證可能不即時，因此高風險事件要搭配短 TTL、Introspection、Revocation List 或 Session Version 等設計。
DPoP 與 mTLS：讓被偷走的 Access Token 不一定能被直接重播
Bearer Token 的特性是任何持有者都能使用。Sender-constrained Token 則把 Token 綁定到 Client 持有的金鑰；Resource Server 除了驗 Token，還要求請求提供能證明持有對應私鑰的資料。RFC 9700 建議使用 OAuth mTLS 或 DPoP 降低 Token 洩漏後的濫用。
DPoP 讓 Client 為每次 HTTP Request 簽一個 Proof JWT，包含目標 URI、Method、時間與唯一識別；Authorization Server 將 Access Token 綁定 Public Key Thumbprint，Resource Server 驗證 Proof、Binding、Freshness 與 Replay。DPoP 不是替代 TLS，也無法阻止同一端點內的惡意程式直接呼叫簽章能力。
mTLS 以 Client Certificate 綁定 Token，適合受管 Server-to-server、高保證金融與企業環境，但需要 Certificate 發放、輪替、Proxy 轉送與終止邊界治理。兩者都要確認每個 Resource Server 真正強制 Sender Constraint，不能只由 Authorization Server 在 Token Claim 標記。
| 模式 | 請求者需證明 | 優勢 | 主要營運議題 |
|---|---|---|---|
| Bearer | 只需持有 Token | 相容性高、簡單 | Token 洩漏可直接重播 |
| DPoP | 每次請求持有 Client 私鑰 | 適合 Public Client、應用層 Proof | Clock、Replay Cache、Key Rotation、Proxy URI |
| mTLS | TLS Client Certificate 私鑰 | 強通道與金鑰綁定 | PKI、Proxy、憑證發放與輪替 |
Client Authentication：Client Secret 不是所有架構的答案
Confidential Client 應在可行時進行 Client Authentication。固定 shared client_secret 易被複製、進 Log、CI 或多環境共用；RFC 9700 建議在合適環境使用 mTLS 或 private_key_jwt 等非對稱方式，Authorization Server 只需保存 Public Key，降低 Server Secret 外洩風險。
private_key_jwt 仍要驗 Issuer／Subject、Audience 指向 Token Endpoint、短 exp、唯一 jti 與簽章 Key，並防止 Assertion 重播。Key Rotation 要支援重疊期、kid、撤銷與失陷處理，不能把長期私鑰直接放在 Repository 或一般環境變數。
SPA、Mobile、Desktop 是 Public Client，即使 App 內有 client_secret 也不能視為機密。其安全依賴 PKCE、Redirect URI、平台 App Link、Token Storage、Attestation／Device Signal 與最小權限，而不是一組能被逆向取得的共同 Secret。
PAR、JAR 與高保證流程：保護複雜 Authorization Request
當 Authorization Request 帶有細緻交易內容、動態 Scope、PII 或高價值金融授權時，把全部參數放在 Browser URL 容易遭竄改、洩漏與長度限制。Pushed Authorization Requests 讓 Client 先經受保護 Back Channel 把 Request 推送至 Authorization Server，取得短效 request_uri，再由 Browser 攜帶參照值。
JAR 可將 Authorization Request 封裝為簽章 JWT，保護完整性與來源。PAR 與 JAR 能降低 Front Channel 參數被修改及敏感資料外洩，但仍需要精確 Redirect、PKCE、Client Authentication、state／nonce、Issuer 驗證與正確 Token 處理。
高保證 API 可再結合 Rich Authorization Requests，以 authorization_details 表達結構化資源與動作，避免 Scope 字串無法描述付款對象、帳號、金額等細節。選用前要確認 Authorization Server、Client、Resource Server 與審計資料的一致支援。
多 Issuer、Discovery 與 Mix-Up：不要讓回應被送到錯的 Authorization Server
支援多個 Identity Provider 或多租戶 Issuer 的 Client 容易遭 Mix-Up：攻擊者讓 Client 以為流程來自某個 Authorization Server，實際 Code／Token Endpoint 或 Issuer 卻屬於另一個。RFC 9700 要求多 Authorization Server Client 驗證 Authorization Response 的 iss，或使用其他符合規格的 Issuer 識別／不同 Redirect URI。
Discovery URL 不能由未受信輸入任意指定後直接抓取 Metadata，否則可能造成 SSRF、惡意 Endpoint、Key Injection 或 Tenant Confusion。應維護允許的 Issuer，精確比對 Metadata issuer，限制 HTTPS、Redirect、DNS 與 Endpoint Host，並 Cache 有效設定。
Client 不應把錯誤訊息中的完整 Code、Token、state 或 nonce 顯示給使用者；多 Issuer Callback 必須先以安全方式找回發起交易，再決定使用哪個 Issuer 驗證，不可相信攻擊者提供的 Query 值。
Scope、Consent 與 Least Privilege：讓 Token 只拿到真正需要的權限
Client 應在使用某功能時才要求所需 Scope，而不是首次登入就要求所有資料與離線存取。Authorization Server 要清楚顯示 Client、資料、動作、期間與第三方接收者，預設不勾選非必要權限，並讓使用者與管理員能查看及撤銷 Grant。
Resource Server 仍要把 Scope 對應到 Route、Method 與業務 Action，並執行 Subject、Client、Tenant、Object、Field 與狀態授權。Scope 命名要穩定、可審計、避免 read_write_all 這類無法最小化的集合；敏感動作可使用結構化 authorization_details 與 Step-up。
Refresh 時不得靜默擴張 Scope／Audience；Token Exchange 與 On-behalf-of 流程也必須限制下游 Token 不超過原始 Actor、Subject 與委派鏈權限。記錄 Granted Scope 與實際使用能協助辨識長期未使用的過度權限。
| 層次 | 要限制什麼 | 驗證位置 |
|---|---|---|
| Audience／Resource | Token 可送到哪個 API | Authorization + Resource Server |
| Scope／Action | 可執行哪些功能 | Resource Server Route／Policy |
| Subject／Client／Tenant | 代表誰、哪個 App、哪個租戶 | Business Authorization |
| Object／Field／State | 能操作哪筆資料與狀態轉移 | Domain Service／Data Layer |
Logout、Revocation 與 Session：不是刪掉一個 Cookie 就結束
OIDC Provider Session、Client 本地 Session、OAuth Grant、Access Token、Refresh Token、Remembered Device 與各 Resource Server Cache 是不同狀態。RP-Initiated Logout 或 Front／Back-channel Logout 要依部署選用；使用者看到『登出所有裝置』時，產品必須定義實際撤銷哪些層級。
Client 刪除 Cookie 不會讓已外洩 Access Token 自動失效；Authorization Server 撤銷 Refresh Token 也未必即時終止離線驗證的 JWT Access Token。可透過短 Access TTL、Introspection、Revocation、Session Version、Event Push 或高風險 Deny List達到風險相稱的終止。
密碼重設、MFA 變更、帳號停用、Client Credential 外洩與 Token Reuse Detection 應觸發明確撤銷政策。撤銷要 Idempotent、可追蹤且跨區域傳播，並定期演練 Provider 中斷時 Fail Closed／Grace 的營運策略。
日誌與監控：看得見攻擊，但不能把 Token 寫進 Log
應記錄 Client、Issuer、Grant／Flow、Redirect URI ID、Subject 的去識別關聯、Scope、Audience、Token／Grant Family 的不可重播識別、成功與失敗原因、PKCE／nonce／state 驗證結果、Refresh Reuse、Revocation 與異常時間線。
不得記錄完整 Authorization Header、Access／ID／Refresh Token、Authorization Code、Client Secret、private_key_jwt、code_verifier 或可重播 Cookie。Query String、Reverse Proxy、APM、Exception、Mobile Crash Report 與客服截圖都需遮罩。只 Hash Token 也要考慮短 Token 空間與跨系統關聯風險，優先使用伺服器產生的安全事件 ID。
重要告警包括 Redirect URI 反覆失敗、固定／重用 state 或 nonce、PKCE Downgrade、Authorization Code 重播、Refresh Token Reuse、未知 kid 洪水、多 Issuer Mix-Up、Audience 錯誤、Scope 異常擴張與 Token 從新地區／裝置大量使用。
測試矩陣：正常登入成功只是最小的一條 Happy Path
測試應依 Client Type × Grant × Issuer × Redirect × Token Type × Resource Server × Role 建矩陣。對每個流程驗證 state、nonce、PKCE、Issuer、Code 單次、Redirect 精確、Token Audience／Scope／Expiry、Refresh Rotation、Revocation 與 Logout。
負向案例要包含省略／修改 code_challenge、plain／S256 降級、重用 Code、交換不同 Client／Redirect 的 Code、錯誤 Issuer、Wildcard Callback、Open Redirect、ID Token 呼叫 API、另一 API 的 Access Token、未知 kid、alg 變更、過期 Token、過大 Clock Skew、Scope 不足與跨 Tenant Object。
Browser 與 Mobile 還要測試 Back／Forward、重整、多分頁、同時登入、多帳號切換、Universal Link／Custom Scheme Claim、App 恢復、無網路、Token Refresh 競態、XSS 與第三方 Script。任何 SDK／IdP 升級都需以攻擊鏈回歸，不只跑單元測試。
| 測試面 | 代表案例 | 預期安全結果 |
|---|---|---|
| Redirect | Wildcard、Open Redirect、未註冊 URI | Authorization Server 拒絕且不送 Code |
| 交易綁定 | 重用／交換 state、nonce、Code、Verifier | Client／Token Endpoint 拒絕 |
| Issuer／Key | 錯誤 iss、未知 kid、惡意 JWKS | 不抓任意 Key、不建立 Session |
| Token 用途 | ID Token 呼叫 API、錯誤 aud／scope | Resource Server 拒絕 |
| Refresh | 舊 Token 重播、並行 Refresh | 偵測 Reuse、撤銷 Family、控制競態 |
| 授權 | 跨租戶 Object、額外欄位與動作 | Server-side Object／Field Policy 拒絕 |
| Session／Logout | Factor 變更、全域登出、Token 洩漏 | 相關 Session／Grant／Token 被撤銷 |
Token 或 Client Credential 外洩時的事件應變
先辨識外洩類型、Issuer、Client、Audience、Scope、Subject、Grant Family、發行時間與最後使用。Authorization Code 通常短效且單次；Access Token 需要縮小影響 API 與時間；Refresh Token 可延續存取；Client Private Key／Secret 則可能影響整個 Client。
立即措施可包括撤銷 Grant／Refresh Family、封鎖 Token ID／Session Version、輪替 Client Credential／Signing Key、限制 Scope／Audience、暫停高風險操作與要求重新驗證。Key Rotation 要考慮已發 Token 驗證、JWKS Cache 與過渡，不應未規劃就刪除所有 Key 造成全面服務中斷。
保存遮罩化事件、Client、IP／裝置、Token Correlation、Refresh Chain、API Action 與資料存取，修復 Token 進 Log、XSS、Redirect、惡意 App、弱儲存或 Provider Credential 的根因，再用重播、撤銷與負向授權案例複驗。
- 不要只改使用者密碼，卻保留 Refresh Token、Grant 與既有 Session
- 不要把完整 Token 貼進工單、聊天室或 Incident Timeline
- 區分單一 Token、Token Family、Client Credential、Issuer Key 與全平台影響
- 確認撤銷已傳播到所有 Resource Server、Cache、Region 與離線驗證服務
- 完成 Root Cause、使用者通知、資料影響分析與攻擊鏈複驗
OAuth／OIDC 上線前最終檢查表
成熟實作不是『串上某家 SSO SDK』，而是每個角色都能證明自己只接受正確 Issuer、Client、Redirect、Audience、Scope、Token Type 與交易。安全設定也必須進入自動化測試、Metadata 管理、Key Rotation、監控與事件應變。
若系統已存在 Implicit、Password Grant、Wildcard Redirect、Browser Client Secret、長效 Bearer Token 或不驗 Audience 的 API，應先建立 Inventory 與風險排序，逐一提供相容遷移與停用日期，而不是在舊流程旁新增一條安全流程後宣告完成。
- 互動式流程使用 Authorization Code + PKCE S256，拒絕 Downgrade
- Implicit 與 Resource Owner Password Credentials Grant 已停用或有明確遷移期
- Redirect URI 精確註冊，Callback 無第三方資源與 Open Redirect
- state、nonce、PKCE Verifier 均交易專屬、綁 Session、驗後失效
- ID Token 完整驗 iss、aud／azp、exp、nonce、Signature 與必要 Claims
- API 完整驗 Access Token Issuer、Audience、Scope、Expiry 與物件授權
- Refresh Token Rotation／Sender Constraint、Reuse Detection 與 Family Revocation 已實作
- Public／Confidential Client 分類正確，Secret／Private Key 有輪替與最小權限
- Token 不進 URL、Log、Analytics、Browser Persistent Storage 或客服工具
- Logout、撤銷、Key Rotation、Provider 中斷與外洩事件已有演練證據
Redmark 在 OAuth／OIDC 安全檢測中的角色與限制
Redmark 可在獲得授權的網站與登入後範圍內，協助辨識 Callback、Session、Cookie、安全標頭、公開 Endpoint、部分 Token 與存取控制的可觀察問題，並透過持續掃描與複驗追蹤修復。
但自動化 DAST 不能單獨證明整個 Federation 安全。多 Issuer Trust、IdP 內部政策、Client Private Key 儲存、Refresh Family 資料模型、所有 Mobile Deep Link、Back-channel Logout、客服復原與跨服務 Object Authorization，仍需架構審查、設定與程式碼檢查、協定測試、IAM Log 分析及人工攻擊鏈驗證。
實務上應把 OAuth Client、Authorization Server、Callback、Token Endpoint、Resource API、Logout、Recovery 與高權限授權流程納入同一份範圍與角色矩陣，讓自動化檢測、人工驗證與身分治理互相補足。
