OpenID Connect Core 1.0(六)使用隐式验证流

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值以防止重放攻击。检测重放攻击的精确方法用于特定客户端的。

posted @ 2018-10-19 08:58 a.thinker 阅读(...) 评论(...) 编辑 收藏