使用IS4进行SSO流程

Question

我们有几个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. 哪一个更好？ （Cookies vs. Token＆＃34; sharing＆＃34;）
2. 我应该实施不同的（即更好的）流程吗？

Answer 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凭证被访问一次，对所有应用程序上下文进行身份验证，并且从那时起基于每个应用程序管理令牌生存期。