这个SSO实施是否安全？

Question

客户要求我们为其供应商设计一个简单的单点登录解决方案。在这种情况下，客户端有许多供应商能够实现一个简单的解决方案，允许供应商的用户登录我们客户的网站。我想出了这个：

共享数据

以下数据将由我们与特定供应商共享。

• user_id - 由供应商提供
• vendor_id - 由我们提供
• vendor_secret - 由我们提供。 “随机”SHA512哈希

共享散列函数

我们的规范将定义以下实践，用于生成适合通过URL参数传输的密钥：

// Pseudo-code. Assume sha512() is a function in their native language that accepts a string and returns a SHA-512 hash
vendor_id = 341;
vendor_secret = "areallylonghash...";
user_id = "12345abcdef;&";
hash = sha512(vendor_id + ":" + vendor_secret + ":" + user_id);

SSO流程

1. 用户点击供应商网站上的“登录”，并向供应商的SSO入口点发出GET请求。
2. 供应商收到关于入口点的请求（例如www.avendor.com/sign_in）。
3. 供应商使用上面的散列函数为用户生成散列。
4. 供应商使用参数vendor_id，user_id和hash重定向到我们客户的终端。
5. 我们在终端收到请求。我们从vendor_id中查找vendor_secret并尝试重新创建发送给我们的hash。
6. 如果生成的哈希值匹配，请在客户端的站点上创建会话。

潜在问题

如果我们使用GET请求进行重定向步骤4，生成的哈希是否可能最终出现在用户的浏览器历史记录中？如果有人可以点击历史记录中的链接，则不太安全。我们可以在重定向时使用HTTP标头传输哈希吗？

如果你已经走到这一步，谢谢你。欢迎所有反馈！我们想确保部署安全的解决方案。

Answer 1

答案：不，这不安全。

在第4步中，用户代理可以访问vendor_id，user_id和hash。现在，客户端可以将他们想要的任何字符串附加到user_id并修改hash以匹配。我不确定我是否完全理解您的提案，但似乎这可能会让一个用户以另一个用户名为自己的前缀的用户登录。

您需要使用HMAC而不是普通哈希。

Stay away from implementing your own crypto!

Answer 2

3（b）供应商使用生成的令牌向您的应用发出API请求

3（c）您的应用使用user_id保存令牌

4（）供应商使用params user_id，vendor_id，token，hash

重定向

如果令牌与api匹配，则登录用户，删除令牌

然后重定向网址是一次性使用

OR

不要做额外的API请求。使用基于时间的旋转RSA密钥。然后重定向URL只能工作5秒或其他任何内容。