所以。我有域 A.com，其中用户身份验证在域 B.com 完成。目前我已将其设置为将登录表单发布到 B.com，它（如果成功）设置会话 cookie 并触发重定向到 A.com/loggedin。但是，由于表单已发布到 B.com 并且 cookie 设置为该域，当我从 A.com 发出 JSON 请求时，会话 cookie 不可用，我不知道他们是否登录。那么问题就变成了，如何解决这个问题？
我一直在考虑一种解决方案，其中我将向重定向 uri 添加一个令牌，然后可以将其用于与 A.com 的一次经过身份验证的会话创建（浏览器可以使用该令牌来验证与 B.com 的会话，这样 cookie 将被设置为 A.com 并在 JSON 请求中可用。之后令牌将失效 ofc)。
但是，我不确定这个解决方案有多安全？还是有其他更安全的解决方案？
您当前的解决方案对我来说看起来不错，可以在这种情况下使用。但是出于安全考虑，您可能希望使用一些好的加密方法对其进行加密，而不是提供普通令牌，并在此基础上配置您的服务器以authentication token在使用它之前对其进行加密和解密。唯一的事情是您需要为您的案例选择最佳算法。
除了这个解决方案，您还可以考虑会话管理工具。Session Migration,Session Replication和Session Sharing是我能想到的选项。
这是Oracle 为会话共享提供的解决方案的链接，我认为这对您的情况有所帮助。
是的，还有更安全的选择。
对于单点登录，有一个名为 OpenID/connect 的开放标准（建立在 oAuth2.0 之上）对于资源共享、授权和身份验证，有 oAuth。
要记住的事情。
利用社区已经完成的工作。
oAuth 1.0a（迄今为止仍被广泛接受为最安全的模式） - https://www.rfc-editor.org/rfc/rfc5849 oAuth 2 - http://oauth.net/2/（使用 openID 构建授权在 oAuth2 之上）
oAuth 2 不是 oAuth 1a 的替代品 - 它是一个全新的（不太安全）的想法，严重依赖 SSL - oAuth1a 仍然是最安全的 - 但仍然与您的实施和对潜在弱点的理解一样好。
您可能正在寻找 openID 连接的想法 - 但 oAuth 信息也很有用......
安全断言标记语言（SAML，发音为“sam-el”[1]）是一种基于 XML 的开放标准数据格式，用于在各方之间交换身份验证和授权数据，特别是在身份提供者和服务提供者之间。SAML 是 OASIS 安全服务技术委员会的产品。SAML 始于 2001 年；SAML 的最新更新是从 2005 年开始的。
SAML 解决的一个最重要的要求是 Web 浏览器单点登录 (SSO)。单点登录解决方案在 Intranet 级别很常见（例如，使用 cookie），但是将这些解决方案扩展到 Intranet 之外一直存在问题，并导致不可互操作的专有技术的扩散。（解决浏览器 SSO 问题的另一种较新的方法是 OpenID 协议。）SAML 规范定义了三个角色：主体（通常是用户）、身份提供者 (IdP) 和服务提供者 (SP)。在 SAML 解决的用例中，委托人向服务提供者请求服务。服务提供者向身份提供者请求并获得身份断言。基于这一说法，
在将身份断言传递给 SP 之前，IdP 可能会向委托人请求一些信息——例如用户名和密码——以便对委托人进行身份验证。SAML 指定三方之间的断言：特别是从 IdP 传递到 SP 的断言身份的消息。在 SAML 中，一个身份提供者可以向许多服务提供者提供 SAML 断言。相反，一个 SP 可能依赖并信任来自许多独立 IdP 的断言。SAML 没有指定身份提供者的身份验证方法；它可能使用用户名和密码，或其他形式的身份验证，包括多因素身份验证。允许用户使用用户名和密码登录的目录服务是身份提供者处身份验证令牌（例如密码）的典型来源。
http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
使用身份验证令牌应该可以正常工作，但请考虑以下几点：
在我看来，这两点对于防止劫持身份验证令牌和重用它非常重要。还要限制令牌的有效时间（30 秒应该没问题），以防止滥用旧的/未使用的令牌。