如何安全地进行跨域身份验证?

时间:2013-11-07 19:53:34

标签: security session authentication

因此。我有域A.com,其用户身份验证在域B.com完成。目前我设置了这样,以便登录表单发布到B.com,如果成功,则设置会话cookie并激活重定向到Aloglogged。但是,当表单发布到B.com并且cookie设置为该域时,当我从A.com执行JSON请求时,会话cookie不可用,我不知道他们是否登录。那么问题就变成了,如何解决这个问题?

我一直在考虑一个解决方案,其中我会向重定向uri添加一个令牌,然后可以用A.com进行一次身份验证会话创建(浏览器可以使用该令牌与B进行身份验证) .com,这样cookie就可以设置为A.com,并且可以在JSON请求中使用。之后令牌将被无效.c。

但是,我不确定这个解决方案有多安全?或者还有其他更安全的解决方案吗?

4 个答案:

答案 0 :(得分:7)

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

除了这个解决方案,您还可以考虑会话管理工具。 Session MigrationSession Replication会话共享是我能想到的选项。

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

答案 1 :(得分:3)

安全断言标记语言(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

答案 2 :(得分:2)

是的,有更安全的选择。

对于Single Sign On,有一个名为OpenID / connect的开放标准(建立在oAuth2.0之上) 对于资源共享,授权和身份验证,有oAuth。

要记住的事情。

  1. 所有这些解决方案都只是控制安全漏洞 - 请谨慎使用。
  2. 所有这些解决方案都让您对XSS,中间人和劫持/重播攻击感到难以理解。
  3. 由于第1点和第2点,谨慎实施至关重要。
  4. 利用社区已经完成的工作。

    oAuth 1.0a(目前仍被广泛认为是最安全的模式) - http://tools.ietf.org/html/rfc5849 oAuth 2 - http://oauth.net/2/(使用openID建立在oAuth2之上的授权)

    oAuth 2不是oAuth 1a的替代品 - 它是一种全新(不太安全)的想法,严重依赖于SSL - oAuth1a仍然是最安全的 - 但仍然只能与您的实施和对潜在弱点的理解一样好。 / p>

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

    SO - starting point of some differences

    openID connect (layered on oAuth 2)

    oAuth concepts

    SO - worth a read

答案 3 :(得分:1)

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

  • 使用强大的PRNG生成令牌,并生成长令牌以防止强制执行
  • 确保使用的令牌会立即失效以防止重播攻击

在我看来,这两点非常关键,可以防止劫持身份验证令牌并重新使用它。同时限制令牌有效的时间(30秒应该没问题),以防止滥用旧/未使用的令牌。