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,token,expiry)三元组
5. 进程与其余部分的初始登录相同

Answer 2

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

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

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

因此，当您通过浏览器访问应用程序 B 时，应用程序 B 会将您的用户代理重定向到身份验证服务器（这又可能将您重定向到 SSO 站点）。

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

因此，SSO cookie 已经存在 - 因为早些时候，应用程序 A 还会将您的用户代理重定向到执行登录的 Auth / SSO 服务器。然后，SSO 服务器可以在您和它之间保留一个 cookie。

我可以查看是否登录到应用程序 A 并检索令牌，然后通过将令牌传递给应用程序 B 来从应用程序 A 启动应用程序 B。

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

1. 应用程序 B 有权访问所请求的范围，并且

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

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

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

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

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