1

我们有几个 Web 应用程序，所有这些应用程序都将适应使用基于 IdentityServer4 和 OpenId Connect 的单个身份验证端点。

我想要一些关于我正在考虑的以下（简化）流程的有争议的建议。

  1. 饼干：

    1. 用户访问app1并点击登录
    2. 用户被带到 IdP 登录页面
    3. 用户登录并返回到app1
    4. app1提供到app2的链接，用户点击该链接
    5. app2将她带到 IdP 登录页面
    6. IdP cookie尚未过期，因此不需要用户凭据。因此，用户会自动登录并返回到app2。

  2. 基于令牌的身份验证：

    1. 用户访问app1并点击登录
    2. 用户被带到 IdP 登录页面
    3. 用户登录并返回到app1
    4. app1提供到app2的链接，用户点击该链接
    5. app1将用户重定向到app2，但也提供了之前从 IdP 获得的id_token （上文第 2.3 项）
    6. app2验证id_token是否有效并自动让用户登录。

问题：

  1. 哪一个更好？（Cookie 与 Token “共享”）
  2. 我应该实施不同的（即更好的）流程吗？
4

1 回答 1

1

流程#2 是首选，这就是我这么认为的原因：

流程 #1 中的关键项目是步骤 1.6，其中评估app1的 cookie 是否过期。这里的关键（在我看来）是 cookie 应该是特定于应用程序的，当app2的用户通过身份验证时，不应测试app1的 cookie。

相反，在流程 #2 中，步骤 2.6 应由app1（作为引用者）执行，因此app1和身份提供者同意身份验证令牌仍然有效，并且app2可以继续使用app1作为延迟身份验证应用程序。

IdP 可以合法地验证（或刷新）来自任何应用程序的令牌，而 cookie 应作为应用程序（或会话）特定的方式进行管理。

第三种更理想的方法： 每个应用程序都应该有自己的来自 IdP 的身份验证上下文，并且当app1进行身份验证时，每个链接的应用程序也可以使用相同的用户凭据进行身份验证。在这种模式下，应用程序可以在不同的时间使令牌过期（例如：查看 2 小时，但只编辑 30 分钟。）这种方法的关键是 SSO 凭证被访问一次，对所有应用程序上下文进行身份验证，并且令牌生命周期是从那时起，按应用程序进行管理。

于 2018-05-07T22:44:43.560 回答