3.3 使用混合流驗證(Authentication using the Hybrid Flow)
本節描述如何使用混合流執行驗證。當使用混合流(Hybrid Flow)時一些令牌從授權端點返回，另一些則從令牌端點返回。混合流中返回令牌的機制在OAuth 2.0多響應型別編碼實踐中指定[OAuth. responses]。
3.3.1 混合流程的步驟（Hybrid Flow Steps）
混合流程遵循以下步驟:
1、客戶準備一個包含所需的驗證請求的請求引數。
2、客戶端傳送請求到授權伺服器。
3、授權伺服器驗證使用者。
4、授權伺服器獲得使用者同意/授權。
5、授權伺服器將終端使用者傳送給回客戶端一個授權碼，根據響應型別，返回一個或多個額外的引數。
6、客戶端使用的這個授權碼到令牌終結點請求響應。
7、客戶端接收到包含一個ID Token和Access Token的body響應。
8、客戶端驗證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)
當使用混合流程，客戶端必須驗證如下響應:
1、驗證的響應符合[OAuth.Responses]的第五節 。
2、遵循RFC 6749的驗證規則，尤其是4.2.2和10.12部分。
3、遵循3.3.2.12驗證規則，驗證ID Token ，response_type 使用的值是“code id_token” 或“code id_token token”。
4、遵循3.3.2.9部分驗證規則，驗證IAccess Token ，當 response_type 使用的值“code token”或“code id_token token”。
5、遵循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驗證授權結點發出的授權碼，客戶端應該執行以下操作:
1、用JWA 中為ID Token的JOSE報頭的alg報頭引數指定的雜湊演算法對程式碼的ASCII表示的八位元組進行雜湊。例如，如果alg是RS256，則使用的雜湊演算法是SHA-256。
2、取雜湊的最左邊一半，然後對其進行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節中定義的那樣。