给定 A.com 上经过身份验证的用户，我们希望将用户重定向到 B.com，以便她立即获得身份验证。我正在考虑的方案非常基本：
A.com 和 B.com 都共享密钥S。
在 A.com 上，将用户重定向到https://B.com/auth?userid= userid &time= current_time &mac= MAC，其中 MAC 为 HMAC-SHA256(userid + time, S)。
B.com/auth 要求给定的 MAC 有效并且时间在时钟的 5 秒内。
鉴于客户端将使用 SSL，我认为重放攻击不太可能，但我提供了一些最低限度的保护。我不需要像 OAuth 登录令牌这样的东西；客户将始终通过此过程访问 B.com。
还有什么我想念的吗？有这样的 SSO 的正式名称吗？
MAC 是正确的工具，HMAC/SHA-256 很好。使用 5 秒容差可能有点乐观：
您必须确保两台服务器都有准确的时钟；使用NTP。此外，请确保您使用定义明确的表示，即 UTC 格式（否则，您会遇到夏令时问题）。
“5 秒延迟”必须足以容纳往返行程：服务器A向客户端发送“重定向”响应，然后客户端连接到B并发送请求。如果客户端处于不利条件（例如，客户端在火车上使用笔记本电脑），网络可能会在几秒钟内不可用。
SSL 可以防止来自外部的重放攻击；包含时间戳是为了击败用户自己的重放攻击。如果服务器乙需要时间戳没有比老ñ秒，那么这意味着，如果你阻止访问用户一个，则该用户仍然可以跟乙的ñ秒。您可能可以容忍更长的n；就个人而言，我会延迟 5 分钟。另一种看待它的方式如下：如果在执行身份验证后，B允许在给定时间范围T内连续请求，例如使用基于 cookie 的会话管理，并且会话在T之后到期秒，那么使用比T短得多的n就没有什么意义了。
请注意，恶意用户可能想要伪造 NTP 数据包以使服务器B的时钟回到过去，以便重用具有长期过期 MAC 的旧身份验证 URL。NTP 数据包未经过身份验证。即使 NTP 服务器声称它已经关闭了几周，普通的 NTP 客户端也不会接受对其时钟进行相当大的更改；ntpdate但是，理论上可能会滥用启动时调用。我在实践中没有观察到这种攻击。
改进建议：
您可能希望在重定向 URL 中包含A和B的标识符（例如服务器名称），并作为 MAC 输入的一部分。这会跟踪谁在进行身份验证+授权，以及用户被授权的服务器。如果您以后想用几个不同的A和B服务器扩展系统，这会更加灵活。
您可以将 MAC 替换为数字签名（RSA、DSA...）：服务器A拥有私钥并使用它进行签名；服务器B使用A的公钥来验证签名。这避免了在A和B之间共享秘密（共享的秘密越多，秘密就越少）。