如何安全地进行跨域认证？答案

【问题标题】：How to do cross-domain authentication securely?如何安全地进行跨域认证？
【发布时间】：2013-11-19 15:41:07
【问题描述】：

所以。我有域 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 请求上可用。之后令牌将失效 c)。

但是，我不确定此解决方案的安全性如何？还是有其他更安全的解决方案？

【问题讨论】：

sso 解决方案怎么样。 A.com需要认证，然后重定向到sso服务器（S.com），S.com返回给用户一个longin表单，发布到S.com。 S.com收到并生成一个token，并用token重定向到A.com，A.com获取到Token，调用S.com获取登录的用户信息。
还有一些，openid 解决方案

标签： security session authentication

【解决方案1】：

您当前的解决方案对我来说看起来不错，可以在这种情况下使用。但是出于安全考虑，您可能希望使用一些好的加密方法对其进行加密，而不是提供普通令牌，并且基于此，您可以配置您的服务器以在使用之前加密和解密authentication token。唯一的问题是您需要为您的案例选择最佳算法。

除了这个解决方案，您还可以考虑会话管理工具。 Session Migration、Session Replication 和 Session Sharing 是我能想到的选项。

这里是Link，供 Oracle 提供的会话共享解决方案，我认为这对您的情况会有所帮助。

【讨论】：

我看不到加密令牌如何提高安全性？服务器必须在重定向用户之前向用户提供令牌。即使令牌被加密，它仍然暴露给任何“观看”的人，例如在中间人攻击中。黑客仍然可以访问会话信息，因为服务器会解密正确的加密令牌......您需要一个类似于 SSH 的高度复杂的算法来保护和验证令牌的完整性。如果你问我，那简直是偏执狂……但是，+1 表示会话共享提示。
就像 Derija 所说，令牌加密并不能解决任何问题，因为它仍然以明文形式传输。但是对于会话共享内容 +1。谢谢！
加密绝对不适用于 Web 浏览器，但对于在客户端也实施加密的其他应用程序（可能是 Swing 应用程序），这将有所帮助。

【解决方案2】：

使用身份验证令牌应该可以正常工作，但请考虑以下几点：

使用强 PRNG 生成令牌，生成长令牌防止暴力破解
确保使用过的令牌立即失效以防止重放攻击

在我看来，这两点对于防止身份验证令牌被劫持和重用都非常重要。还要限制令牌的有效时间（30 秒应该没问题），以防止滥用旧的/未使用的令牌。

【讨论】：

对令牌进行签名怎么样？否则 B.com 怎么知道令牌是由 A.com 发行的？

【解决方案3】：

是的，还有更多安全选项。

对于单点登录，有一个名为 OpenID/connect 的开放标准（建立在 oAuth2.0 之上）对于资源共享、授权和身份验证，有 oAuth。

注意事项。

所有这些解决方案都只不过是受控的安全漏洞 - 请谨慎使用。
所有这些解决方案都让您容易受到 XSS、中间人以及劫持/重放攻击的攻击。
由于第 1 点和第 2 点，仔细实施至关重要。

利用社区已经完成的工作。

oAuth 1.0a（至今仍被广泛认为是最安全的模式）-https://www.rfc-editor.org/rfc/rfc5849 oAuth 2 - http://oauth.net/2/（使用基于 oAuth2 的 openID 进行授权）

oAuth 2 不是 oAuth 1a 的替代品 - 它是一个全新的（不太安全）的想法，严重依赖 SSL - oAuth1a 仍然是最安全的 - 但仍然与您的实施和对潜在弱点的理解一样好。

您可能正在寻找 openID 连接的想法 - 但 oAuth 信息也很有用...

SO - starting point of some differences

openID connect (layered on oAuth 2)

oAuth concepts

SO - worth a read

【讨论】：

我完全不相信这里接受的答案。加密令牌是不够的。如果没有签名和身份验证，这肯定很容易受到攻击吗？
OAuth 1.0 绝对应该不被使用，因为它已被 OAuth 2.0 淘汰，正如 RFC 中明确指出的那样：tools.ietf.org/pdf/rfc6749.pdf

【解决方案4】：

安全断言标记语言（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 没有指定身份提供者的身份验证方法；它可能使用用户名和密码，或其他形式的身份验证，包括多因素身份验证。允许用户使用用户名和密码登录的目录服务是身份提供者处身份验证令牌（例如密码）的典型来源。流行的常见互联网社交网络服务还提供身份服务，理论上可用于支持 SAML 交换。

http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

【讨论】：