我认为您误解了单点登录的工作原理。
让我们考虑想要使用单点登录的 website1 和 website2。
在 identityProvider 处创建一个登录网站。这是唯一出现登录屏幕的地方。
当用户访问 website1 并选择登录 website1 时,会将用户发送到 identityProvider 的登录屏幕。用户登录到 identityProvider ,它会为其域删除自己的登录 cookie(并且可能允许用户保存他们的身份验证信息,这样他们就不会再收到提示了)。然后它将浏览器重定向回 website1,包括请求中的令牌,website1 会打开该令牌,从中获取身份信息并执行它自己的登录位(丢弃它自己的身份验证 cookie,它可以持续使用它想要的任何时间)。
然后用户访问website2并选择登录。Website2 将用户退回到 identityProvider,后者已经知道用户是谁,如果他们的用户选择保存他们的登录信息,则会静默进行身份验证,然后使用另一个令牌重定向回 website2,website2 会打开该令牌,然后执行自己的登录位。
它周围有很多安全措施,将令牌限制在特定网站上,只允许将令牌发送到白名单网站等。
所以为了解决你的担忧
- 用户登录 website1,然后移动到 website2。website2如何知道用户已经登录?它没有。website2 必须首先从单点登录站点请求身份验证信息。
- 这意味着我需要将 website1 中的所有 url 编组到 website2?不,除非您也将 website1 设为身份提供者。即便如此,那也会很痛苦,如果需要令牌,最好让 website2 重定向回身份提供者。
- 其次,如果用户继续浏览 website2 1 小时,然后移动到 website1。到那时 website1 会话已经超时,所以用户会看到一个登录页面,不是吗?- 这取决于您如何配置 website1,以及它的身份验证 cookie 持续多长时间。
- 但是根据单点登录功能,这种行为是错误的。不,这不对。单点登录并不意味着您获得了在站点之间共享的浮动令牌。每个使用单点登录的网站仍会创建自己的身份验证 cookie。可能发生的情况是,如果用户返回到 website1,它会检测到过期的身份验证 cookie,然后再次将用户发送到单点登录页面,在该页面上对他们进行身份验证(静默),并将新令牌推送回 website1,从而创建一个新的自己的身份验证cookie。