787 VIEWS
Pinterest LinkedIn LINE

你們很多人可能都知道，我在 Authlete 工作。1外部董事2我們也在做儘管如此，我還是沒能了解最新的情況，所以森川先生講座影片我決定研究一下。在過去的幾周里，FAPI 工作組一直在討論如何編寫輪換刷新令牌時的實施行為指南。

在本影片中，Morikawa 先生介紹了 Authlete 的支援 OAuth 和 OIDC 分析的功能。主要項目有：

  1. 什麼是剖析？：自行選擇OAuth/OIDC規範並進行詳細設定。
  2. 授權者簡介：用於建立 OAuth/OIDC 相容的授權伺服器和 ID 提供者的 Web API 服務。
  3. 代幣發行背景：代幣生命週期管理和發行的背景。
  4. 客戶特徵：以鍵值格式管理客戶端屬性並使用它們進行授權決策。
  5. 範圍管理：詳細的範圍管理和 RAR3靈活的授權請求。
  6. 實體和訊息的置信度
    • 客戶端認證：支援多種認證方式
    • 請求/回應認證：支援多種認證方式（PKCE、PAR、JARM）。
  7. 資源所有者意圖：提高安全性和使用者體驗
  8. 已發行代幣的特徵：配置和管理有效期限、屬性和所有權證明（MTLS、DPoP）。
  9. 代幣發行後管理：保留刷新令牌的輪換和冪等性。
  10. 令牌撤銷API：引進一個新的 API 來使令牌失效。

下面，我們將仔細研究它們。照常 奧蒂奧·艾伊 這是使用的總結。它還包含一些補充原始影片的內容。4像往常一樣，如果您能指出任何錯誤，我將不勝感激。

在 YouTube 上觀看此視頻.
播放影片將連接到 YouTube。

什麼是剖析（0:48)

分析是指在實際應用 OAuth 和 OIDC 時進行必要的詳細設定和選擇。具體來說，這包括從規範所指示的選項中選擇必要的選項，從後來出現的擴展規範中決定使用哪一個，甚至在規範範圍之外做出各種決定。典型範例包括使用者身份驗證和範圍設定。分析包括以下：

  • 實際應用OAuth/OIDC時的詳細設定和選擇工作。
  • 從規範提供的選項中選擇您需要的內容，並決定如何使用擴充規範。
  • 有許多決策超出了規範的範圍（例如使用者身份驗證、範圍設定）。
  • 這包括決定範圍名稱和結構等細節。

Authlete 簡介 (1:35)

Authlete 是一項服務，提供使用 Web API 建置授權伺服器和身分提供者的部分。這使得開發人員可以輕鬆實現複雜的 OAuth/OIDC 協定處理和令牌生命週期管理。 Authlete的主要特點是：

  1. 作為 Web API 提供：
    • Authlete 以 Web API 的形式提供授權伺服器功能。這使得開發人員可以輕鬆地從他們的應用程式中呼叫授權處理。
  2. 授權引擎和OIDC引擎：
    • 授權伺服器和 ID 提供者通常表示為「授權引擎」或「OIDC 引擎」。這是因為 Authlete 支援多種規範和分析，並且可以靈活地自由選擇和實現它們。
  3. OAuth/OIDC 元件即服務：
    • 最近，Authlete 越來越多地被引入為「OAuth/OIDC 元件即服務」。這意味著Authlete的服務不僅僅是提供API，而是全面提供建置和運作授權伺服器所需的元件。
  4. 協議處理和令牌生命週期管理：
    • Authlete 負責檢查其收到的授權請求的參數，並據此指導後續步驟。該流程包括檢查接收到的請求訊息，如果沒有問題，則頒發令牌並執行生命週期管理。
  5. 相容於各種規格和型材：
    • Authlete 支援各種 OAuth/OIDC 規範和分析實作。這使開發人員可以自由選擇和實施最適合其用例的規格。
  6. 知識庫管理：
    • 授權者是知識庫我們經營 Authlete 並發布有關如何使用它及其功能的資訊。這提供的資訊甚至非用戶也可以用來設計和實作 OAuth/OIDC 伺服器。

Authlete 提供了一個全面的解決方案，可輕鬆建置和操作授權伺服器和身分提供者。 它足夠靈活，可以適應各種規範和分析，其特點是為開發人員提供了靈活性。

代幣發行上下文（03:42)

導致代幣發行的環境和背景（上下文）由多種因素組成。了解此上下文可以闡明存取控制和授權流程的結構。主要內容是：

  1. 客戶特徵：
    • 授權伺服器管理客戶端的許多屬性。例如，客戶端是第一方應用程式還是第三方應用程式、機密客戶端還是公共客戶端、Web應用程式還是本機應用程式等。
    • Authlete 以鍵值格式管理用戶端屬性，並在授權請求期間使用該屬性資訊做出授權決策。
  2. 範圍：
    • 範圍描述了資源的操作權限，但由於它被定義為簡單的字串，因此可能很難詳細管理權限。
    • Authlete 提供了範圍屬性功能，可讓您將任意資訊以鍵值格式連結到範圍。也可以對每個客戶端可以請求的範圍設定限制。
  3. 實體和訊息的置信度：
    • 包括客戶端身份驗證和請求回應保護（例如 PKCE、PAR、JARM 等）。
    • 支援客戶端認證方式和請求參數保護方式的設定。
  4. 資源所有者意圖：
    • 您可以向最終使用者呈現授權請求中請求的範圍，並讓他們選擇允許的範圍。這種實作方法也可以使用Authlete的API來建置。
  5. 代幣生命週期：
    • 管理存取令牌和刷新令牌的生命週期，從頒發到使用、更新、失效和刪除。
    • 我們還提供了一個功能，可讓您為每個授權伺服器、範圍和用戶端設定每個令牌的有效期。
  6. 所有權證明 (PoP)：
    • 透過使用 MTLS 和 DPoP，我們提供了一種機制來證明存取權杖的使用者是合法所有者。

透過這些元素，Authlete 有助於複雜的授權流程和令牌生命週期管理。用於授權決策和令牌管理的各種配置和功能允許開發人員選擇和實施最適合其應用程式的配置。

客戶特徵（05:20)

當授權伺服器頒發令牌時，客戶端特徵扮演重要角色。具體來說，會考慮以下因素：

  1. 管理實體：
    • 第一方應用程式學生第三方應用程式區別。
    • 第一方是指由開發者直接控制的應用程式；第三方是指由第三方提供的應用程式。
  2. 客戶類型：
    • 保密客戶學生公共客戶區別。
    • 機密客戶端是可以安全地保存客戶端秘密（私鑰）的客戶端（伺服器端應用程式）。
    • 公共客戶端是無法安全維護客戶端機密的客戶端（例如本機或單頁應用程式）。
  3. 申請表：
    • 網路應用程式，本機應用程式，單頁應用程式 (SPA)特徵因客戶類型而異。
  4. 客戶屬性管理：
    • Authlete 允許您為每個客戶端設定任意屬性。鍵值格式提供管理功能。
    • 這允許根據設定為客戶端屬性的資訊靈活地處理授權請求。
  5. 處理授權請求：
    • 授權伺服器參考從客戶端接收的授權請求中包含的客戶端ID，並檢查與其關聯的客戶端屬性。
    • 此客戶端屬性資訊用於做出授權決策。

客戶端屬性設定範例

在 Authlete 的管理控制台畫面中，您可以設定客戶端屬性，如下所示：

  • 鑰匙：affiliation
  • 價值：partner

基於此信息，授權伺服器可以應用特定於特定客戶端的處理。

具體例子

  • 第一方客戶端（內部應用程式）：允許對高特權範圍的請求。
  • 第三方客戶端（其他公司的應用程式）：僅允許有限的範圍。

這是對客戶特徵以及如何管理和利用它們的概述。詳情客戶端屬性 KBo參照。

範圍管理（07:02)

範圍是OAuth和OIDC中用來表達資源存取權限的參數。範圍管理是透過設定和限制範圍來控制使用者和用戶端擁有的存取權限的關鍵要素。 Authlete 提供了一些有關範圍管理的功能：

  1. 範圍的基本結構：
    • 範圍參數：簡單地定義為字串並包含在請求中以請求特定權限。但是，單獨作為字串的範圍名稱可能不足以表達該範圍的詳細權限。
  2. 建置範圍：
    • 範圍屬性：Authlete 提供了「範圍屬性」功能，可讓您以鍵值格式將任意資訊連結到範圍。這允許您管理有關範圍的詳細元資料。
    • 範圍範例：
      • 範圍名稱：read_profile
      • 範圍屬性：鍵值（例如鍵level，價值high）
    您可以使用管理畫面 UI 設定每個範圍的詳細設定。
  3. 每個客戶的範圍限制：
    • Authlete 提供了限制每個用戶端可以請求的範圍的能力。這允許對特定客戶端可用的範圍進行細粒度控制。
    • 例：客戶端 A 已確定範圍read_profile只允許，客戶端 B 處於範圍內read_profile學生edit_profile允許。
  4. 動態範圍：
    • 動態範圍：參數化範圍名稱的方法。例如，consent:12345使用範圍名稱和附加資訊的組合，例如：
    • 常用表達：您可以在作用域名稱上使用正規表示式來動態產生符合您要求的作用域名稱。 Authlete 透過將正規表示式指定為範圍屬性來允許動態範圍管理。
  5. 豐富的授權請求 (RAR)：
    • RAR（豐富的授權請求）：一種擴展規範，可以實現比範圍更詳細、更靈活的授權請求。authorization_details使用參數指定更細粒度的存取權限。
    • Authlete允許您為每個客戶端配置此RAR設置，以實現詳細的權限管理。

範圍管理的實作範例

在Authlete的管理控制台中，您可以設定範圍和屬性，如下所示：

  • 範圍名稱：read_profile
  • 屬性鍵：level
  • 屬性值：high

這允許範圍read_profile可以進行精細化管理。

實體和訊息的置信度（10:06)

客戶端身份驗證（10:50)

客戶端身份驗證是客戶端與授權伺服器安全通訊的重要機制。特別是對於機密客戶端，令牌端點需要客戶端身份驗證。具體來說，這包括：

1. 選擇身份驗證方法

  • 主要的客戶端認證方法有：
    • 客戶秘密：最基本的方法，使用客戶端 ID 和客戶端金鑰（相當於密碼）。
    • 用戶端憑證 (mTLS)：使用客戶端憑證建立雙向 TLS 進行身份驗證。
    • 以智威湯遜：使用 JSON Web Token (JWT) 的客戶端身份驗證方法。
    • 其他：根據客戶的不同，每個設備可能需要特殊的方法。

2. Authlete 中的設置

  • Authlete 允許您定義一組支援的用戶端身份驗證方法作為服務（授權伺服器）端配置。此設定允許授權伺服器決定允許哪些身份驗證方法。
  • 客戶端設定：設定每個客戶端使用哪種身份驗證方法。這允許您為每個客戶端選擇適當的身份驗證方法並確保安全性等級。

3. Authlete 提供的功能

  • 強制認證方式:Authlete 提供了一個功能，可讓您強制使用身份驗證方法。這包括配置為所有客戶端強制使用特定的身份驗證方法。
  • 服務等級和用戶端層級的靈活配置允許身份驗證滿足安全要求。

4. 具體例子

  • 服務設定：在Authlete管理控制台中指定授權伺服器支援的客戶端認證方式（例如：client_secret_basic，client_secret_post，client_secret_jwtETC。
  • 客戶端設定：在各個客戶端設定中，從上面列出的方法中選擇該客戶端要使用的身份驗證方法。例如，一位客戶client_secret_basic在另一個客戶端中client_secret_jwt可以配置使用。

另外，雖然不是所謂的客戶端認證，但是對於公共客戶端來說是必需的，即使不是，仍然需要PKCE [RFC7636]5我們也支持

請求-響應認證（12:02)

關於請求/回應認證，支援PKCE、PAR和JARM。

PKCE（12:02)

概要

  • 說明：PKCE 是用來保護 OAuth 2.0 授權程式碼流的擴充規範。專為提高公共客戶的安全性而設計。
  • 介紹理由：降低無法安全維護用戶端機密的公共用戶端（例如行動應用程式或單頁應用程式）的授權碼被盜的風險。

結構體

  • 程式碼挑戰：當客戶端發出授權請求時code_challenge發送參數。
  • 程式碼驗證器：後續的令牌請求需要客戶端code_verifier發送。授權伺服器是這個code_verifier，code_challenge如果它們匹配，將頒發令牌。

授權支援

  • 強迫性:Authlete 有一個強制使用 PKCE 的設定。例如，您可以要求所有客戶端使用 PKCE。
  • 指定挑戰方法：S256也可以強制使用程式碼質詢方法，例如

PAR [RFC9126]（13:36)

概要

  • 說明:PAR是在授權伺服器中預先註冊授權請求參數並對其進行保護的規範。降低透過使用者代理程式（瀏覽器）發送授權請求所帶來的安全風險。
  • 介紹理由：這是一種防止授權請求參數暴露給前端後被竄改的機制。

結構體

  • 預登記：提前將所有授權請求參數，包括客戶端認證等傳送給授權伺服器。
  • 請求URI：授權伺服器傳回請求URI並使用該URI執行授權請求。

授權支援

  • 專用API：Authlete提供了專用的API來處理PAR請求，透過使用它，授權伺服器可以輕鬆實現PAR。

賈姆（14:43)

概要

  • 說明:賈姆6是保護 JWT 格式的授權回應的規格。這確保了授權回應的完整性和真實性。
  • 介紹理由：透過對授權回應的內容進行加密和簽名，我們防止了過程中被篡改的風險。

結構體

  • JWT 格式：授權伺服器以 JWT（JSON Web Token）形式傳回授權回應。 JWT 已簽名，有時也進行了加密。
  • 回應驗證：當客戶端收到回應時驗證 JWT，檢查其完整性和頒發者的合法性。

授權支援

  • 多重簽名演算法：Authlete 支援 JARM 回應的多種簽章和加密演算法。
  • 配置靈活：可以為每個客戶端配置 JARM 使用情況。

資源所有者意圖（15:13)

資源所有者意圖是指資源所有者（通常是最終使用者）在提交授權請求時指定允許哪些範圍的過程。透過使用 Authlete，您可以建立反映資源所有者意圖的彈性授權流程。

1. 基本思維方式

  • 用戶參與：向資源擁有者提供授權請求中包含的範圍，並讓他選擇允許哪些範圍。
  • 靈活的權限：透過僅允許資源所有者特定範圍來防止過度授權。

2. 實施方法

  • 使用 Authlete 的 API：您可以自訂授權要求的處理，並允許資源擁有者使用您建立的使用者介面 (UI) 檢查和選擇範圍。
  • 知識庫指南：權威知識庫詳細說明了實現這一目標的具體步驟。
    • 向最終使用者顯示授權請求中請求的範圍。
    • 選擇最終使用者允許的範圍。
    • 根據選擇結果產生最終的授權回應。

3. 具體例子

  • 提交授權請求：
    1. 接收客戶的授權請求。
    2. 資源所有者請求的範圍（例如read_profile，edit_profile) 顯示在 UI 畫面上。
    3. 如果資源擁有者有特定範圍（例如read_profile僅有的）。
  • 範圍權限和回應：
    1. 最終範圍根據資源所有者的選擇確定。
    2. 產生包含所選範圍的授權回應。
    3. 僅在授權令牌中包含選定的範圍。

4. 知識庫的使用

  • 具體代碼和指南：
    • 權威知識庫包含具體的 API 使用範例和程式碼範例來實現這些流程。
    • 提供實施細節和逐步指南來幫助您高效開發。

設計反映資源所有者意圖的授權流可為最終使用者提供更多控制權，從而提高安全性和使用者體驗。此外，透過利用 Authlete 的功能，可以順利實施此流程。

到目前為止，您現在可以發行代幣了。接下來，我們將解釋所發行的代幣的特徵。

已發行代幣的特徵（16:05)

有效期

  • 如何決定：可以為每個授權伺服器、範圍、客戶端設定token有效期。也可以在發放token時指定特定的有效期限作為請求參數。
  • 優先事項：如果同時滿足多個條件，則適用最短的有效期限。
  • 配置靈活：Authlete 允許您為每個令牌設定以秒為單位的有效期，並且還提供了一個 API，可讓您動態更改有效期以滿足發行時的特定條件。

令牌屬性

  • 概要：任何屬性都可以連結到鍵值格式的令牌。
  • 典型屬性：客戶端ID、使用者識別碼、範圍、客戶端分類、使用者角色等。
  • 使用：資源伺服器在驗證令牌時使用它來獲取有關令牌的頒發者和上下文的詳細信息，而不僅僅是令牌是否有效。

如何將任意屬性與令牌關聯知識庫o參照。

如何將屬性傳遞給資源伺服器

  • 訪問令牌格式：
    • 標識符類型：資源伺服器內省token取得資訊。
    • 封閉型：屬性資訊直接嵌入到令牌本身。
    • 混合型：結合了上述兩個優點的方法。

擁有證明

  • MTLS（相互 TLS）：
    • 結構體：使用 TLS 用戶端憑證進行身份驗證並將令牌和用戶端憑證連結起來。授權伺服器檢查憑證是否提前註冊。也要檢查資源伺服器上的憑證。
    • 使用 TLS 用戶端憑證頒發存取令牌 參考
  • DPoP（證明性所有權證明）：
    • 結構體：使用公鑰和私鑰對產生 DPoP Proof JWT 並將其連結到存取權杖。它是一種在應用層實現所有權證明的機制。
    • 設定值：Authlete 允許設定強制逐一客戶端使用 DPoP。
    • 使用 DPoP 參考

代幣發行後管理（22:38)

刷新令牌的連續使用和輪換

  • 繼續使用：設定繼續使用刷新令牌值而不更新它。
  • 迴轉（不要繼續使用）：更新刷新令牌值並頒發新令牌。每次刷新令牌時該值都會變更。
  • 重置有效期限：更新刷新令牌值時，可以選擇是否重設有效期。一旦重置，有效期限將重新開始計算。
  • 有效期限的延續：新刷新令牌的過期時間設定為舊刷新令牌的過期時間。
  • 細節是，刷新令牌的連續使用設定在裡面

刷新令牌的冪等性 (24:27)

  • 令牌並行刷新問題：設定為更新token值時，每次刷新token時，刷新token值都會更新。那麼，當短時間內來自多個客戶端的多個令牌請求時，除了第一個之外的所有請求都會導致無效令牌錯誤。
  • 解決決策:Authlete 透過設定刷新令牌冪等性來緩解這個問題，當短時間內有多個刷新請求使用相同的刷新令牌時，為所有請求返回相同的新刷新令牌。

令牌撤銷 API (26:02)

令牌撤銷 API 提供根據條件撤銷特定令牌或所有相關令牌的功能。這對於維護安全性和防止不必要的令牌使用非常重要。

1. 基本功能

  • 個別令牌撤銷：您可以使特定的存取令牌或刷新令牌失效。
  • 根據條件撤銷：允許您撤銷與特定用戶端或資源擁有者相關的所有令牌。

2. 如何請求撤銷

  • 客戶的請求：
    • 符合 RFC 7009：透過指定存取令牌或刷新令牌值使令牌無效的標準規範。實施方法：使用 Authlete 的令牌撤銷 API，客戶端使特定令牌失效。
     POST /revoke HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

     token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token
  • 來自資源擁有者/授權伺服器的請求：
    • 根據條件撤銷：立即使與用戶端和資源擁有者相關的所有令牌（存取令牌和刷新令牌）失效。

    • API使用:Authlete 的新令牌撤銷 API 允許更靈活地設定撤銷條件。
     POST /api/auth/token/revoke
     Host: api.authlete.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

     {          "subject": "リソースオーナーの識別子", 
          "client_id": "クライアントID"
     }

3. 使用範例

  • 示例 1：如果使用者更改密碼，與該使用者關聯的所有存取令牌和刷新令牌都將過期。
  • 示例 2：如果發現客戶端應用程式行為不當，與該客戶端關聯的所有令牌將立即撤銷。

4. 過期和令牌管理

  • 過期令牌：Token撤銷處理基本上是針對有效期限內的Token，但是過期的Token也需要從資料庫中刪除進行管理。
  • 撤銷後的處理：過期的 token 無法重複使用，資源伺服器會進行內省以驗證 token 的有效性。

Authlete 的令牌撤銷 API 為這些不同的場景提供了靈活性和安全性。這可以實現安全有效的代幣管理。

摘要

  • 對於OAuth/OIDC profiling，需要考慮導致授權的情況、資源伺服器請求資訊、生命週期管理和安全措施等。
  • 當前最佳實踐（BCP）和 FAPI 等
  • 授權模板雅API參考您可以參考

註腳

  1. Authlete支援高安全性OAuth/OIDC實施並推廣FAPI（金融級API）等標準。
  2. 我作為外部董事參與，因為他們陸續實施了新的規範。
  3. 豐富的授權請求
  4. Otio本來應該只使用目標文檔等來創建材料，但由於視頻在加載時使用GPT-4o轉換為文本，所以看起來Masu會在那時對其進行補充。
  5. 讀法：Pixie（精靈）
  6. JWT 安全授權模式