瀏覽器驗證

瀏覽器驗證會將應用程式請求指派給使用者或工作負載身分。應用程式必須定義認證資料的 存放位置、哪些請求會攜帶認證資料、瀏覽器如何限制這些資料，以及伺服器如何使其失效。

工作階段與 Cookie #

對於具有同網站後端的瀏覽器應用程式，Cookie 中的不透明工作階段識別碼可讓認證資料不被 JavaScript 存取。將工作階段狀態儲存在伺服器端，在驗證後及權限變更後輪換識別碼，並在 登出或閒置時使其過期。

設定 Secure、HttpOnly 以及適當的 SameSite 值。Secure 要求使用 HTTPS，HttpOnly 可防止 JavaScript 存取，而 SameSite 可降低跨網站請求偽造的暴露風險。SameSite 不能 取代 CSRF 防禦：會變更狀態的 Cookie 驗證端點應驗證 CSRF 權杖，或要求使用應用程式明確 信任的來源。

OAuth 2.0 與 OpenID Connect #

OAuth 2.0 將授權委派給授權伺服器；其本身不會標準化使用者驗證。OpenID Connect 增加 身分層與 ID 權杖。瀏覽器型公開用戶端應使用含 PKCE 的 Authorization Code，並驗證 state、使用 OpenID Connect 時的 nonce、精確的重新導向 URI、issuer、audience、expiry 及 signature。

不要將存取權杖放入可能出現在記錄、參照來源及瀏覽器歷程記錄中的 URL 查詢字串或片段。 Backend-for-Frontend 可以將權杖保留在伺服器端，並向瀏覽器公開應用程式工作階段 Cookie。

SAML #

SAML 會在身分識別提供者與服務提供者之間交換已簽署的 XML 判斷。根據已設定的中繼資料 驗證判斷的簽章，並驗證 issuer、audience、recipient、時間條件及請求關聯。XML 簽章驗證 必須使用受維護的函式庫和強化的剖析器；手寫 XML 或簽章處理並不安全。

Bearer 權杖 #

JWT 是權杖格式，而不是工作階段協定。資源伺服器必須驗證簽章或取得受信任的內省結果， 然後驗證 issuer、audience、expiry、not-before 時間及任何授權宣告。將未過期的 Bearer 權杖視為認證資料：使用較短的存取權杖存留期、以範圍為基礎的授權、金鑰輪換，以及符合 應用程式風險特性的撤銷設計。

未經驗證時，不要將權杖內容用作授權決策。加密權杖並不會免除驗證宣告的必要性。