OpenID Connect Core 1.0（六）使用隱式驗證流

3.2 使用隱式驗證流（Authentication using the Implicit Flow）

本節描述如何使用隱式流程執行驗證。使用隱式流程時，全部令牌從受權終結點返回；不使用令牌終結點返回。

隱式流程主要是由客戶在瀏覽器中使用腳本語言實現。直接返回Access Token和ID Token到客戶端，這可能會讓他們接觸到最終用戶和應用程序，這些用戶能夠訪問終端用戶的用戶代理。受權服務器不進行客戶端驗證。

 

3.2.1隱式流程步驟（Implicit Flow Steps）

隱式流程動遵循如下步驟:

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

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

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

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

五、受權服務器將終端用戶返回給客戶端，並使用ID Token，若是須要的話，則可使用一個Access Token。

六、客戶端驗證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）

使用隱式流程時，客戶端必須驗證響應以下:

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

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

三、按照3.2.2.11部分的ID Token驗證規則。

四、按照3.2.2.9部分的Access Token驗證規則,除非 response_type 使用的值是 id_token。

 

3.2.2.9 Access Token驗證（Access Token Validation）

要驗證帶有ID Token的受權端點發出的Access Token，客戶端應該作到如下幾點:

一、用JWA 中指定的哈希算法對access_token的ASCII表示進行散列計算，以得到ID令牌的JOSE Header的alg頭參數。例如，若是alg是RS256，那麼使用的散列算法是SHA-256。

二、取最左邊的一半哈希和base64url編碼。

三、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的內容，除了在本節中指定的差別。

一、客戶端必須使用JWS的方法來驗證 ID Token 的簽名，其算法是在JOSE Header的alg頭參數中指定。。

2. 必須檢查nonce 聲明值，以驗證它是否與在認證請求中發送的值相同。客戶端應該檢查nonce值以防止重放攻擊。檢測重放攻擊的精確方法用於特定客戶端的。