Token Introspection

用於在執行期確認一個 Token 是否仍然有效，以及它當下所代表的身分與權限範圍。在無法或不應該自行驗證Token的情況下，由授權伺服器進行決策。

通常使用在資源伺服器向授權伺服器即時驗證：

1. Token 是否仍然有效
2. Token 是否已被撤銷
3. Token 的 權限範圍 (Scope) 與 關聯用戶 (Subject)

工作流程

1. 客戶端使用 AccessToken 請求資源
2. 資源伺服器將 Token 傳送至授權伺服器的 introspection_endpoint(專門用來驗證 Token 的 API)。
3. 授權伺服器檢查資料庫，回傳 Token 的即時狀態。
4. 根據 Token 狀態，通過則允許存取；否則立即拒絕。

回應資料

若 Token 有效，則應該回傳以下資訊：

1. Token 所屬的 Principal
2. 可用的 Scope 或權限
3. Token 的 Issuer 與 Audience

---

Opaque Token

根據之前對 Opaque Token 的介紹，其本身只是一個識別碼，必須依賴 Introspection 才能使用。

JWT

JWT 原則上不需要 Introspection。但在以下情境中仍可能搭配使用：高風險操作、短時間內需要強制失效既有 Token

效能優化議題

頻繁的 Introspection 請求會增加授權伺服器的負擔並導致延遲：

1. 短效快取：資源伺服器可將 Introspection 結果快取 30-60 秒。
2. 負面快取：針對已撤銷的 Token，應拉長快取時間，防止惡意攻擊。
3. 重要性分級：只有在高風險操作（如扣款、更動個資）時，才強制執行實時進行 Token 檢查。

對於 JWT 來說，通常會使用 Token BlackList + Bloom Filter 兩個機制，快速檢查 Token 是否在撤銷名單中，彌補無法即時撤銷的缺點。