Single sign on 使用IS4的SSO流

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

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

Cookies：

用户访问app1并点击登录

用户被带到IdP登录页面

用户登录并返回到app1

app1提供指向用户单击的app2的链接

app2将她带到IdP登录页面

IdPCookie尚未过期，因此不请求任何用户凭据。因此，用户将自动登录并返回到app2

基于令牌的身份验证：

用户访问app1并点击登录

用户被带到IdP登录页面

用户登录并返回到app1

app1提供指向用户单击的app2的链接

app1将用户重定向到app2，但也提供先前从IdP获得的id_令牌（上文第2.3项）

app2验证id\u令牌是否有效，并自动让用户登录

问题:

哪一个更好？（Cookies与令牌“共享”）

我是否应该实施不同的（即更好的）流程

流#2是首选，以下是我为什么这么认为的原因：

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

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

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

第三种更理想的方法： 每个应用程序都应该有自己的来自IdP的身份验证上下文，当app1进行身份验证时，每个链接的应用程序也可以使用相同的用户凭据进行身份验证。在此模式中，应用程序可以在不同的时间使令牌过期（例如：查看2小时，但仅编辑30分钟）

---

这种方法的关键在于，SSO凭据只访问一次，对所有应用程序上下文进行身份验证，从那时起，每个应用程序都可以管理令牌生存时间。

感谢您的快速响应！小提示：在上面的步骤1.6中，是IdP验证IdP域cookie（由浏览器提供）是否已过期，并避免要求用户再次提供其凭据。因此，没有web应用尝试检查其他web应用的cookie。关于理想的方法，您指的是像AZA这样的模式吗？在这种模式中，授权代理（尽管它可能是身份验证代理）被放在所有应用程序前面来处理SSO？您在澄清IdP域cookies方面做得很好，是的，AZA概括地说就是我描述的模式，虽然AZA描述代理只是为了AAA目的…如果您总是在那里输入，或者更灵活地说，任何应用都可以从AZA接口集继承，那么任何入口点都将成为AZA。我不同意re flow 2。客户端应用程序只能验证直接颁发给它的id_令牌。流#2不是一个标准流#1是正确的方法，只要我们都同意IDP的auth cookie允许无seemless SSO。IDP cookie确实是允许无seemless SSO的cookie。您是否有实现令牌基身份验证的示例，如上文所述。很遗憾，我不想学。我们最终选择了选项1，它与IS4一起提供。