OpenID Connect Core 1.0（七）使用混合流驗證

3.3 使用混合流驗證(Authentication using the Hybrid Flow)

本節描述如何使用混合流執行驗證。當使用混合流(Hybrid Flow)時一些令牌從受權端點返回，另外一些則從令牌端點返回。混合流中返回令牌的機制在OAuth 2.0多響應類型編碼實踐中指定[OAuth. responses]。

3.3.1 混合流程的步驟（Hybrid Flow Steps）

混合流程遵循如下步驟:

一、客戶準備一個包含所需的驗證請求的請求參數。

二、客戶端發送請求到受權服務器。

三、受權服務器驗證用戶。

四、受權服務器得到用戶贊成/受權。

五、受權服務器將終端用戶發送給回客戶端一個受權碼，根據響應類型，返回一個或多個額外的參數。

六、客戶端使用的這個受權碼到令牌終結點請求響應。

七、客戶端接收到包含一個ID Token和Access Token的body響應。

八、客戶端驗證ID Token和檢索終端用戶的 Subject 標識符。

 

3.3.2 受權終結點（Authorization Endpoint）

當使用混合流程，使用受權的終結點，是以3.1.2節定義的受權碼流程的同樣的方式使用受權的終結點，除了在本節中指定的差別。

 

3.3.2.1 驗證請求（Authentication Request）

驗證請求是由3.1.2.1節中定義 ，除了如下使用的驗證請求參數:

response_type

必需的。肯定要使用的受權處理流的OAuth 2.0響應類型值，包括從使用的端點返回的參數。當使用混合流程，此值是「code id_token」 ，「code token」,或「code id_token token」。這些值定義在 OAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses]。

下面是一個使用混合流的非規範示例請求，該混合流將由用戶代理髮送到受權服務器，以響應客戶機相應的HTTP 302重定向響應(換行僅爲顯示):

  GET /authorize?

    response_type=code%20id_token

    &client_id=s6BhdRkqt3

    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb

    &scope=openid%20profile%20email

    &nonce=n-0S6_WzA2Mj

    &state=af0ifjsldkj HTTP/1.1

  Host: server.example.com

 

3.3.2.2 驗證請求驗證（Authentication Request Validation）

當使用混合流程，驗證請求的驗證方式與第3.1.2.2節中定義的受權代碼流相同。

 

3.3.2.3 受權服務器驗證用戶（Authorization Server Authenticates End-User）

當使用混合流程，終端用戶身份驗證的執行方式與第3.1.2.3節中定義的受權代碼流相同。

 

3.3.2.4受權服務器得到用戶贊成/受權（Authorization Server Obtains End-User Consent/Authorization）

當使用混合流程，最終用戶贊成的得到方式與第3.1.2.4節中定義的受權代碼流相同。

 

3.3.2.5成功的驗證響應（Successful Authentication Response）

當使用混合流程，以隱式流程3.2.2.5節中定義的一樣方式驗證響應，除了在本節中指定的差別。

這些受權終結點結果的使用方式以下:

access_token

OAuth 2.0Access Token。當 response_type 使用的值是 code token，或 code id_token token返回。(token_type 值也在一樣的狀況下返回。)

id_token

ID Token。當 response_type 使用的值是code id_token 或 code id_token token時返回。

code

受權碼。當使用混合流時，其老是返回。

下面是一個非規範化成功的響應使用混合流程的例子(換行僅爲顯示):

  HTTP/1.1 302 Found

  Location: https://client.example.org/cb#

    code=SplxlOBeZQQYbYS6WxSbIA

    &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso

    &state=af0ifjsldkj

 

3.3.2.6 驗證錯誤響應（Authentication Error Response）

當使用混合流程，受權錯誤響應的方式與第3.1.2.6節中定義的受權代碼流相同，除了在本節中指定的差別。

若是最終用戶拒絕請求或最終用戶身份驗證失敗，受權服務器必須在重定向URI的片斷組件中返回錯誤受權響應，OAuth 2.0 (RFC6749) 4.2.2.1中定義和 OAuth 2.0多個響應類型編碼實踐 (OAuth.Responses) 中定義，除非指定不一樣的響應模式。

 

3.3.2.7 重定向URI片斷處理(Redirect URI Fragment Handling)

當使用混合流程，重定向的URI參數處理片斷與隱式流程3.2.2.7部分中定義請求相同。同時參照 15.5.3節中URI片斷處理實現注意事項。

 

3.3.2.8 身份響應驗證(Authentication Response Validation)

當使用混合流程，客戶端必須驗證以下響應:

一、驗證的響應符合[OAuth.Responses]的第五節 。

二、遵循RFC 6749的驗證規則，尤爲是4.2.2和10.12部分。

三、遵循3.3.2.12驗證規則，驗證ID Token ，response_type 使用的值是「code id_token」 或「code id_token token」。

四、遵循3.3.2.9部分驗證規則，驗證IAccess Token ，當 response_type 使用的值「code token」或「code id_token token」。

五、遵循3.3.2.10部分規則，驗證受權碼，當 response_type使用的值是「code id_token 」或「code id_token」。

 

3.3.2.9 Access Token驗證（Access Token Validation）

當使用混合流時，從受權終結點返回的Access Token將以與隱式流相同的方式進行驗證，如3.2.2.9節中定義的那樣。

 

3.3.2.10 受權碼驗證（Authorization Code Validation）

要使用ID Token驗證受權結點發出的受權碼，客戶端應該執行如下操做:

一、用JWA 中爲ID Token的JOSE報頭的alg報頭參數指定的哈希算法對代碼的ASCII表示的八字節進行哈希。例如，若是alg是RS256，則使用的哈希算法是SHA-256。

二、取散列的最左邊一半，而後對其進行base64url編碼。

3. 若是ID Token中存在c_hash，則ID Token中的c_hash值必須與前一步中生成的值匹配。

 

3.3.2.11 ID Token

ID Token的內容如第2節所述。當使用混合流時，如下ID Token聲明的這些附加要求適用於受權終結點返回的ID Token:

nonce

nonce 聲明是必需。

at_hash

Access Token的哈希值。它的值是access_token值的ASCII表示的最左半哈希的base64url編碼，其中使用的哈希算法是ID Token的JOSE頭的alg頭參數中使用的哈希算法。例如，若是alg是RS256，那麼用SHA-256散列access_token值，而後取最左邊的128位，base64url對其進行編碼。at_hash值是一個區分大小寫的字符串。

若是ID Token使用access_token值從受權終結點發出，則須要使用access_token，這是response_type值代碼id_token的狀況;不然，它是可選的。

c_hash

Code 的哈希值。它的值是Code的ASCII表示的最左半哈希的base64url編碼，其中使用的哈希算法是ID Token的JOSE報頭的alg報頭參數中使用的哈希算法。例如，若是alg是HS512，用SHA-512對Code進行哈希，而後取最左邊的256位，base64url對其進行編碼。c_hash值是一個區分大小寫的字符串。

若是ID Token是經過從受權終結點發出的Code，對於response_type值code id_token和code id_token來講，這是必需的；不然，它是可選的。

 

3.3.2.12 ID Token驗證（ID Token Validation）

在使用混合流時，必須以與隱式流相同的方式驗證從受權終結點返回的ID Token的內容，如3.2.2.11節中定義的那樣。

 

3.3.3 令牌終結點（Token Endpoint）

在使用混合流時，令牌終結點的使用方式與第3.1.3節中定義的受權代碼流相同，但本節中指定的差別除外。

 

3.3.3.1 令牌的請求（Token Request）

當使用混合流時，令牌請求的方式與受權代碼流的方式相同，如3.1.3.1節中定義的那樣。

 

3.3.3.2 請求令牌驗證（Token Request Validation）

在使用混合流時，令牌請求的驗證方式與在3.1.3.2節中定義的受權代碼流相同。

 

3.3.3.3 成功的令牌響應

當使用混合流時，令牌響應的方式與受權代碼流的方式相同，如3.1.3.3節中定義的那樣。

 

3.3.3.4 令牌錯誤響應

當使用混合流時，令牌錯誤響應的方式與受權代碼流相同，如3.1.3.4節中定義的那樣。

 

3.3.3.5 令牌響應確認

在使用混合流時，令牌響應的驗證方式與在3.1.3.5節中定義的受權代碼流相同。

 

3.3.3.6 ID Token（ID Token）

在使用混合流時，從令牌終結點返回的ID Token的內容與從受權終結點返回的ID Token的內容相同，如3.3.2.11節中定義的那樣，但本節中指定的差別除外。

若是一個ID Token從受權終結點和令牌終結點返回，對於response_type值code id_token和code id_token來講就是這樣，那麼iss和sub聲明值在這兩個ID Token中必須是相同的。任何一方中出現的關於身份驗證事件的全部聲明都應該出如今雙方中。若是任何一個ID Token都包含關於最終用戶的聲明，那麼在二者中出現的任何聲明都應該具備相同的值。注意，出於隱私緣由，OP可能選擇從受權終結點返回關於最終用戶的最少聲明。從ID Token牌終結點返回，at_hash和c_hash聲稱能夠省略，即便這些聲明出如今從受權終結點中返回的 ID Token中，由於ID Token和Access Token值，在令牌終結點中返回時已經經過TLS加密並綁定在一塊兒。

3.3.3.7 ID Token驗證（ID Token Validation）

在使用混合流時，從令牌端點返回的ID令牌的內容必須以與在3.1.3.7節中定義的受權代碼流相同的方式進行驗證。

3.3.3.8 Access Token（Access Token）

若是一個從令牌的終結點的Access Token受權端返回,當 response_type 值是 「code id_token」和 「code id_token token」 ，它們的值多是相同的或者他們可能會有所不一樣。注意，可能會有不一樣的Access Token返回，這是因爲兩個端點的不一樣安全特性以及它們授予的資源的使用壽命和訪問時間可能也不一樣。

3.3.3.9 Access Token驗證（Access Token Validation）

當使用混合流時，從令牌端點返回的訪問令牌將以與受權代碼流相同的方式進行驗證，如3.1.3.8節中定義的那樣。