3.2 使用隱式驗證流（Authentication using the Implicit Flow）
本節描述如何使用隱式流程執行驗證。使用隱式流程時，所有令牌從授權終結點返回；不使用令牌終結點返回。
隱式流程主要是由客戶在瀏覽器中使用指令碼語言實現。直接返回Access Token和ID Token到客戶端，這可能會讓他們接觸到終端使用者和應用程式，這些使用者可以訪問終端使用者的使用者代理。授權伺服器不進行客戶端驗證。
3.2.1隱式流程步驟（Implicit Flow Steps）
隱式流程動遵循以下步驟:
1、客戶準備一個包含所需的驗證請求的請求引數。
2、客戶端傳送請求到授權伺服器。
3、授權伺服器驗證使用者。
4、授權伺服器獲得使用者同意/授權。
5、授權伺服器將終端使用者返回給客戶端，並使用ID Token，如果需要的話，則可以使用一個Access Token。
6、客戶端驗證ID Token和檢索終端使用者的從屬識別符號。
3.2.2 授權終結點（Authorization Endpoint）
當使用隱式流程時，是以3.1.2節定義的授權碼流程的一樣的方式使用授權的終結點，除了在本節中指出的差異。
3.2.2.1驗證請求（Authentication Request）
驗證請求是由3.1.2.1節中定義，除了如下驗證請求引數:
response_type
必需的。OAuth 2.0授權處理流程規定的響應型別值，包括返回終結點的引數。使用隱式流時，這個值是 “id_token token” 或 “id_token” 。這兩個值的含義在OAuth 2.0多個響應型別編碼實踐 [OAuth.Responses] 中定義。沒有Access Token值時只返回 id_token 。
注意：雖然OAuth 2.0還定義了隱式流程令牌響應型別值，但OpenID Connect不使用這種響應型別，因而沒有返回ID Token。
redirect_uri
必需的。將發回響應的URI重定向。這個URI必須精確匹配客戶端預註冊的OpenID提供者的一個重定向URI值，匹配執行在 6.2.1節 (RFC3986) (簡單的字串比較) 中描述。當使用隱式流程時，重定向的URI 不能使用 http方案，除非客戶端是一個本地應用程式,在這種情況下,它可能使用 http: 主機名是localhost。
nonce
必需的。用於將客戶端會話與ID Token關聯起來的字串值，並減輕重播攻擊。該值在請求ID Token中是不會修改的。nonec必須足夠複雜，以防止攻擊者猜測。實現說明,請參閱 15.5.2節 。
下面是一個非規範化的，使用隱式流程請求示例，這將是由使用者代理髮送到授權伺服器，為以響應客戶端相應的HTTP 302重定向響應（換行僅用於顯示目的）:
GET /authorize?
response_type=id_token%20token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid%20profile
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj HTTP/1.1
Host: server.example.com
3.2.2.2驗證請求驗證（Authentication Request Validation）
使用隱式流程時，其驗證請求，與在 3.1.2.2節中定義的授權碼流程方式一致。
3.2.2.3授權伺服器驗證使用者（Authorization Server Authenticates End-User）
使用隱式流程時，終端使用者執行驗證，與在 3.1.2.3節中定義的授權碼流程方式一致。
3.2.2.4授權伺服器獲得使用者同意/授權（Authorization Server Obtains End-User Consent/Authorization）
使用隱式流程時，終端使用者同意，與在 3.1.2.4節中定義的授權碼流程方式一致。
3.2.2.5成功的驗證響應（Successful Authentication Response）
使用隱式流程時，驗證響應與在 3.1.2.5節中定義的授權碼流程方式一致。
使用隱式流程時，所有響應引數新增到重定向的URI片段元件中，在 OAuth 2.0有多個響應型別編碼實踐 (OAuth.Responses)，除非指定不同的響應模式。
下列引數將從授權終端返回：
access_token
OAuth 2.0的Access Token。該值會返回，除非所使用的 response_type 值是id token。
token_type
OAuth 2.0令牌型別的值。該值必須是Bearer或另一個與授權伺服器協商好了的token_type 值。客戶實現這個配置，必須支援 OAuth 2.0使用的Bearer令牌 (RFC6750)規範。配置僅僅描述了使用Bearer令牌。access_token返回情況相同。
id_token
必需的。ID Token。
state
OAuth 2.0狀態值。如果state引數是出現在授權請求中。客戶端必須確認state值是否等於授權請求時傳入的state值。
expires_in
可選的。從響應發生到Access Token過期時間的秒數。
OAuth 2.0 (RFC6749) 中4.2.2節，當使用隱式流程沒有code結果返回。
下面是一個使用隱式流成功響應的非規範示例（換行僅用於顯示目的）：
HTTP/1.1 302 Found
Location: https://client.example.org/cb#
access_token=SlAV32hkKG
&token_type=bearer
&id_token=eyJ0 … NiJ9.eyJ1c … I6IjIifX0.DeWt4Qu … ZXso
&expires_in=3600
&state=af0ifjsldkj
3.2.2.6驗證錯誤響應（Authentication Error Response）
當使用隱式流程，授權錯誤響應與在 3.1.2.6節中定義的授權碼流程方式一致。
如果終端使用者拒絕了請求，或者終端使用者身份驗證失敗，授權伺服器必須在重定向URI的片段元件中返回錯誤授權響應，OAuth 2.0 (RFC6749) 4.2.2.1中定義的和 OAuth 2.0多個響應型別編碼實踐 (OAuth.Responses)，除非指定不同的響應模式。
3.2.2.7重定向URI片段處理（Redirect URI Fragment Handling）
由於響應引數在重定向URI片段值中返回，所以客戶端需要讓使用者代理解析片段編碼的值，並將其傳遞給客戶端的處理邏輯以供消費。有關URI片段處理的實現說明，請參閱第15.3節。
3.2.2.8驗證響應驗證（Authentication Response Validation）
使用隱式流程時，客戶端必須驗證響應如下:
1、驗證的響應符合第五節 (OAuth.Responses) 。
2、遵循RFC 6749的驗證規則，尤其是4.2.2和10.12部分。
3、按照3.2.2.11部分的ID Token驗證規則。
4、按照3.2.2.9部分的Access Token驗證規則,除非 response_type 使用的值是 id_token。
3.2.2.9 Access Token驗證（Access Token Validation）
要驗證帶有ID Token的授權端點發出的Access Token，客戶端應該做到以下幾點:
1、用JWA 中指定的雜湊演算法對access_token的ASCII表示進行雜湊計算，以獲得ID令牌的JOSE Header的alg頭引數。例如，如果alg是RS256，那麼使用的雜湊演算法是SHA-256。
2、取最左邊的一半雜湊和base64url編碼。
3、ID令牌中的at_hash值必須與上一步中生成的值相匹配。
3.2.2.10 ID Token（ID Token）
ID Token的內容在第二節中描述。使用隱式流程時，要求以下額外的宣告申請ID Token:
nonce
使用 nonce 宣告在隱式流中是必需。
at_hash
Access Token 雜湊值。它的值是base64url編碼，它是 access_token 值的ASCII表示的八進位制雜湊中最左半部分的編碼，其中使用的雜湊演算法是在ID令牌的JOSE 標頭的alg頭引數中使用的雜湊演算法。例如，如果alg是RS256，用SHA-256將 access_token 值雜湊，然後用最左邊的128位和base64url編碼它們。at_hash值是一個大小寫敏感字串。
如果帶有 access_token值的 ID Token從授權端點頒發 ，當response_type值是id_token token，這是必需的；當response_type值是id_token時 access_token不會使用。
3.2.2.11 ID Token驗證（ID Token Validation）
使用隱式流程時，必須以3.1.3.7中定義授權碼流程的同樣方式驗證ID Token的內容，除了在本節中指定的差異。
1、客戶端必須使用JWS的方法來驗證 ID Token 的簽名，其演算法是在JOSE Header的alg頭引數中指定。。
2. 必須檢查nonce 宣告值，以驗證它是否與在認證請求中傳送的值相同。客戶端應該檢查nonce值以防止重放攻擊。檢測重放攻擊的精確方法用於特定客戶端的。