如何在两个网站间基于OAuth实现SSO及跨域认证跳转？

一、跨域跳转维持认证状态的处理逻辑 #

要实现从firstsite.com跳转至secondsite.com后自动保持认证，核心是让两个站点在跳转过程中安全传递认证凭证，且第二个站点能有效验证凭证：

• 用户在firstsite.com登录成功后，后端生成一次性、短时效的临时认证凭证（比如加密的授权码）
• 跳转时通过安全机制传递该凭证（避免直接暴露在URL中）
• secondsite.com后端收到凭证后，通过预先建立的服务器间信任关系（比如共享密钥）向firstsite.com校验凭证合法性
• 校验通过后，secondsite.com为用户创建本地会话，完成自动认证

二、共享已认证会话的最常用方式 #

1. 单点登录（SSO）架构 #

这是跨域共享认证的标准方案，主流实现包括：

• OAuth2.0 + OpenID Connect：firstsite.com作为身份提供商（IdP），secondsite.com作为服务提供商（SP）。用户在IdP登录后，SP通过授权码流程获取用户身份信息，创建本地会话。
• SAML：基于XML的企业级协议，通过加密断言传递用户身份，后端直接校验断言合法性。
• 子域名Cookie共享：若两个站点属于同一主域名的子域名（如a.example.com和b.example.com），可设置Cookie的Domain为.example.com，实现跨子域会话共享；完全不同域名场景需配合后端跨域验证。

2. 共享会话存储+后端同步 #

• 两个站点共用分布式会话存储（如Redis、Memcached），用户在firstsite.com登录后，会话数据写入共享存储。
• 跳转时携带加密的会话凭证，secondsite.com后端从共享存储读取会话数据，验证后创建本地会话。

3. 服务器间主动会话同步 #

利用后端信任通道（如签名验证的API接口），用户在firstsite.com登录成功后，firstsite.com主动调用secondsite.com的接口，传递加密后的用户身份信息，secondsite.com直接为用户创建会话。

三、跳转URL中使用查询参数传递OAuth Token是否安全？ #

绝对不安全，原因如下：

• URL会被记录在浏览器历史、书签、服务器日志、代理日志中，Token一旦泄露，攻击者可直接冒充用户。
• 部分浏览器或第三方工具会默认记录URL参数，进一步增加泄露风险。

替代方案：

• 使用POST表单提交跳转：将凭证放在表单隐藏字段中，通过POST请求提交到secondsite.com，参数不会暴露在URL中。
• 后端生成一次性临时授权码：跳转时携带授权码，secondsite.com后端用授权码向firstsite.com换取Token（该过程在后端完成，用户无法直接获取Token）。

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