从第三方发起登录的用例

时间:2019-04-13 20:29:40

标签: openid-connect oidc

开放式ID Connect 1.0核心规范的第4部分规定:

  

在某些情况下,登录流程是由OpenID提供程序或另一方而不是依赖方发起的。在这种情况下,启动器将在其登录启动端点处重定向到RP,该端点请求RP向指定的OP发送验证请求。该登录启动端点可以是RP上的深层链接,而不是默认的登录页面。支持OpenID Connect动态客户端注册1.0 [OpenID.Registration]的RP使用initiate_login_uri Registration参数注册此端点值。

     

发起登录请求的一方通过将以下参数重定向到RP上的登录发起端点来实现:

     

iss   需要。 RP向其发送身份验证请求的OP的颁发者标识符。它的值必须是使用https方案的URL。   login_hint   可选的。向授权服务器提示最终用户可能使用的登录标识符。如果客户端收到此字符串值参数的值,则它必须将它作为login_hint参数值包含在身份验证请求中。   target_link_uri   可选的。验证后请求RP重定向到的URL。 RP必须验证target_link_uri的值,以防止用作外部站点的开放重定向器。   这些参数既可以使用HTTP GET方法作为查询参数进行传递,也可以作为在用户代理中自动提交的HTML表单值进行传递,从而通过HTTP POST方法进行传输。

     

如果扩展定义了其他参数,则可以发送。客户端必须忽略所有无法理解的使用参数。

     

客户端应该使用帧破坏和其他技术来防止最终用户在不知道的情况下通过Clickjacking等攻击通过第三方站点登录最终用户。有关更多详细信息,请参阅[RFC6819]的4.4.1.9节。

假设我在OP service.com上注册了一个RP客户端foo,我想知道它在客户端foo指示指令OP service.com将请求中继到另一个类似Google的OP的用例中的适用性。 。 RP最终如何收到id_token。

1 个答案:

答案 0 :(得分:1)

它不适合您的用例:

  • foo是RP,因此可以是发起方:第4节说登录流程是由OpenID提供商或另一方发起的
  • 但是foo不能指示service.com中继到google,因为service.com是OP,而不是RP,第4节仅谈到重定向到RP:发起登录请求的一方这样做通过重定向到RP上的登录启动端点

因此,第4节不适用于您的用例。

一种匹配用例的方法是让service.com同时充当OP和SP:service.com可以充当foo的OP和google的SP。 FranceConnect实现了这种用例的示例。这是法国的公共服务,在客户面前充当IdP(OP)(例如法国公共服务,例如医疗保险),并在法国公共身份提供者(某些公共行政机构,例如公共财政部门)。这样,最终用户将连接到初始服务,该服务将该用户重定向为作为OP的FranceConnect,将FranceConnect作为SP将该用户重定向为另一个OP,此最终OP将用户重定向回FranceConnect,从而获得用户的身份。从最终的OP,然后将用户重定向到初始服务,该服务从FranceConnect获得用户的身份(FranceConnect之所以知道该身份,是因为它以前是从最终OP获得的)。

这是此用例的UML序列图:

UML sequence diagram