SSO（单点登录）如何工作

Question

我正试图绕过SSO。我的理解是，SSO允许您登录一次并访问多个应用程序（如果您有权限）。所以，我登录到App A.我建立了一个令牌。该令牌如何可供App B使用，因此我不必再次登录App B（假设用户有权使用A和B）？我的应用是AngularJs应用。我访问.Net WebAPis获取数据。

我可以看到我是否登录到App A并检索令牌然后通过将令牌传递给App B从App A启动App B.这样，App B就有了令牌并可以发送到服务器以确保用户可以访问B.但是，如果用户直接打开浏览器并转到App B，那么他们的会话如何与现有令牌建立？

如果答案是后端服务器上的会话状态，那么会话状态如何与App A中登录的用户匹配App B的新请求？

感谢。

Answer 1

嗯，有很多方法可以实现它，它可能很棘手。我可以给你一个解决方案作为例子：

考虑不同子域上的两个应用程序：

The Fine Corinthian Turkey Shop (turkey.example.com)
Rent a Baboon (monkey.example.com)

这两个网络应用想要分享登录，并安排第三个托管网站进行单点登录：

sso.example.com

然后流程是：

1. 弗兰克访问http://turkey.example.com/orders/12
2. 土耳其重定向到https://sso.example.com/login
3. SSO向用户显示登录表单，验证并发出令牌
4. 令牌保存在SSO上的cookie中。
5. 用户现在已在SSO上验证，但需要将令牌恢复为火鸡。
6. SSO在服务器上存储（Guid，Token，Expiry）的组合，其中Guid是随机guid，Expiry是30秒。
7. SSO在包含Guid
的* .example.com上设置安全Cookie
8. SSO重定向回http://turkey.example.com/orders/12
9. 土耳其现在可以从cookie中检索票证
10. 土耳其呼叫SSO服务器并交换令牌的票证。
11. 土耳其将令牌存储在浏览器中（通常是cookie）

现在让我们想象弗兰克想要一些好吃的多汁狒狒和火鸡一起吃：

1. 弗兰克访问：http://monkey.example.com/order-in-bulk
2. Monkey发现Frank没有存储令牌并重定向到https://sso.example.com/login
3. SSO发现Frank已经登录，因为他有一个存储的令牌。
4. SSO在服务器上存储新的（Guid，令牌，到期）三元组
5. 流程与其余部分的初始登录相同

Answer 2

  

但是，如果用户直接打开浏览器并转到App B，那么如何操作   他们的会话是否使用现有令牌建立？

     

如果答案是后端服务器上的会话状态，那么   会话状态如何与使用新用户登录App A的用户匹配   请求App B？

我会说它更多关于cookie和重定向而不是令牌。一旦建立了用户的身份，就生成令牌。

因此，当您通过浏览器点击App B时，App B会将您的用户代理重定向到Auth服务器（可能会将您重定向到SSO站点）。

需要注意的是，SSO登录请求实际上是浏览器和SSO服务器之间的HTTP请求。

因此SSO cookie已经存在 - 因为之前，App A也会将您的用户代理重定向到执行登录的Auth / SSO服务器。然后，SSO服务器可以在您和它之间保留cookie。

  

我可以看到我是否登录App A并检索令牌然后启动App B.   从App A通过将令牌传递给App B。

我不确定我是否理解App A将其令牌传递给App B.通常，Apps（Oauth 2.0客户端）不会共享令牌。应用程序B应向Auth服务器发出自己的请求（如果用户已登录）可能会跳过登录部分，但需要验证：

1. App B拥有所请求范围的权利

2. 已登录的用户已授予对这些范围的访问权限。

如果用户已登录并且之前已批准范围访问，那么除了一堆重定向之外，所有这些处理对最终用户都是无缝的。

这假设您使用隐式授权流程（我注意到您的某个应用程序是angularjs应用程序）。

如果您使用代码，密码或客户端凭据Oauth2.0授予，则您可能会在初始用户登录和同意后收到刷新令牌。

刷新令牌等同于长期访问（仅适用于该应用），无需再次登录并获得最终用户的同意。

Answer 3

sso.example.com存储cookie和Frank进入monkey.example.com时的cookie帮助。如果sso.example.com认为cookie太旧，则可以再次要求登录auth。