自定义跨站自动登录安全验证：如何确保用户来自指定网站？

你的这个场景其实很典型——跨站信任登录，但确实不能依赖$_SERVER['HTTP_REFERER']，这玩意儿不仅容易被伪造，很多浏览器或隐私插件还会直接屏蔽它，完全不靠谱。想验证请求确实来自网站B，给你几个实际可行的方案：

1. 使用HMAC签名的请求参数（最推荐） #

这是行业通用的安全做法，核心是让网站B和A共享一个仅双方知晓的保密密钥，通过签名验证请求合法性：

• 网站B生成跳转链接时，除了唯一哈希值，还要带上这些参数：
  • 唯一哈希（比如用户标识的哈希值）
  • 时间戳（防止重放攻击，比如限制链接10分钟内有效）
  • HMAC签名：用密钥对哈希+时间戳的组合加密（示例代码：hash_hmac('sha256', $hash . $timestamp, $secret_key)）
• 用户点击链接跳转到网站A后，A取出参数，用相同密钥和算法重新计算签名，和链接中的签名对比：
  • 签名一致 → 确认链接由网站B生成
  • 同时检查时间戳是否在有效期内，避免攻击者复用旧链接
• 注意：密钥必须严格保密，只能存储在双方后端服务器中，绝对不能暴露给前端。

2. 提前建立后端级别的会话关联 #

如果网站B和A属于同一主体（比如同一家公司的两个站点），可以让B的后端提前通知A：

• 用户在网站B登录后，B的后端调用A的API接口，发送用户唯一标识+即将使用的哈希值，同时带上双方约定的验证信息（比如同样用HMAC签名）
• A的后端收到请求后，把哈希值和用户标识绑定存储（比如用Redis，设置15分钟过期时间）
• 用户点击链接到A时，A检查哈希值是否存在于绑定关系中：
  • 存在则允许自动登录，随后立即删除该哈希值（防止重复使用）
  • 不存在则拒绝登录

为什么不能获取网站B的IP？ #

别走这条路了——用户点击链接时，请求是从用户浏览器发起的，网站A拿到的$_SERVER['REMOTE_ADDR']是用户的客户端IP，根本不是网站B的服务器IP。网站B并没有直接向A发送请求，所以没法通过IP验证来源。

额外安全补充 #

• 唯一哈希值必须是一次性的，使用后立即失效，哪怕签名验证通过，也不允许同一个哈希多次登录
• 可以把用户代理（User-Agent）加入签名参数中，虽然它能被伪造，但能作为额外的辅助验证层
• 如果涉及敏感操作，自动登录后可要求用户输入一次密码或进行二次验证（比如短信验证码），进一步提升安全性

内容的提问来源于stack exchange，提问作者slavkovl