我正在研究 SSO 机制。我已经设置并创建了一个带有登录屏幕的身份验证服务器。SSO 应该像这样工作(到那时它已经在工作了):
- 当访问客户端应用程序且用户未登录时,重定向到 SSO Auth 领域
- 当用户未登录时,在 SSO Auth 领域上,显示登录屏幕
- 登录后创建会话变量(或者当用户已经登录时 - 会话变量存在)并使用存储在会话中的令牌重定向回来
- 回到客户端应用程序时,获取令牌,将其存储到会话中并通过 SSO Auth 领域请求 user_id
cURL
- 当在客户端应用程序和用户登录时重复
4.
每个请求的点以确保用户仍然登录并在服务器以错误响应响应时在客户端上执行注销
前 3 点效果很好,但我对第 4 点(和第 5 点)有疑问,因为似乎当 cURL 请求 SSO Auth 领域时,那里不存在会话(或者为 cURL 请求创建了一个新会话) .
因此我想问:
- 如何使 SSO Auth 领域应用程序访问现有会话并将 cURL 响应中的信息返回给客户端应用程序?
- 或者有什么更好的方法来做这个检查?
只是一些不明显的信息:
- 所有客户端应用程序和 SSO Auth 领域应用程序都有自己的会话
- 进行检查的原因是检查用户是否没有在不同的客户端应用程序上注销(会话在 SSO Auth 领域没有过期) - 如果是,我们也必须在当前的应用程序上注销他
- 通过 SSO Auth 领域,我只是指负责登录用户的应用程序
- 登录后
user_id
无法直接使用令牌进行传输,因为这将是一个巨大的安全漏洞 - 然后我可以通过使用包含一些随机令牌和现有用户 ID 的 URL 打开客户端应用程序,让自己以任何可能的用户身份登录......
编辑:现在我已经通过使用 SSO Auth 领域的 PHPSESSID 作为令牌解决了这个问题。这样我可以PHPSESSID=TOKEN
使用 cURL 设置 cookie,请求现在访问现有会话,但我不喜欢使用领域的 PHPSESSID 作为可以在 URL 重定向中看到的令牌的想法......有人知道更好的解决方案吗?