然而,如果用户直接打开浏览器并进入App B,那么他们的会话如何与现有令牌建立联系呢?
如果答案是后端服务器上有会话状态,那么如何将App A中已登录的用户与App B的新请求匹配呢?
我认为这更多涉及到Cookie和重定向,而不是令牌。令牌是在用户身份验证后生成的。
所以当您通过浏览器访问App B时,App B会将您的用户代理重定向到认证服务器(该服务器可能会将您重定向到SSO站点)。
需要注意的是,SSO登录请求实际上是您的浏览器和SSO服务器之间的HTTP请求。
因此,SSO cookie已经存在-因为早些时候,App A也会将您的用户代理重定向到认证/SSO服务器,在那里进行登录。然后,SSO服务器可以在您与其之间保持cookie。
我可以看到如果我登录到App A并检索令牌,然后通过将令牌传递给App B从App A启动App B。
不确定我是否理解了App A将其令牌传递给App B的问题。通常应用程序(OAuth 2.0客户端)不会共享令牌。App B应该向认证服务器发出自己的请求,该服务器(如果用户已登录)可以跳过登录部分,但然后需要验证:
1. App B是否具有所请求的范围的权限,以及
2. 登录的用户是否已授予对这些范围的访问权限。
如果用户已登录并且先前已批准了范围访问权限,则所有这些处理对最终用户来说都是无缝的,除了一堆重定向。
这假设您使用隐式授权流(我注意到您的应用程序之一是angularjs应用程序)。
如果您使用代码,密码或客户端凭据Oauth2.0授权,则可能会在用户首次登录和同意后收到刷新令牌。
刷新令牌相当于长期访问(仅针对该应用程序),而无需再次进行登录和获得用户的同意。
HTML5本地存储
使所有工作都得以实现,但这是否也意味着使用SSO必须要使用JS? - Timo Huovinen