基于JWT的单点流跨域认证

Question

web上有很多关于使用JWT (Json Web Token)进行身份验证的信息。但是，当在多个域环境中使用JWT令牌作为单个登录解决方案时，我仍然没有找到一个清晰的解释。

我在一家在不同主机上有很多网站的公司工作。让我们使用example1.com和example2.com。我们需要一个单一的登录解决方案，这意味着如果用户在example1.com上进行身份验证，我们希望他也能在example2.com上自动进行身份验证。

使用example1.com流，我了解到希望在OpenId连接上进行身份验证的用户将首先被重定向到身份验证服务器(或OP："OpenId Provider")。用户在该服务器上进行身份验证，然后使用签名的JWT令牌将用户重定向回原始的example1.com站点。(我知道还有另一个流返回一个中间令牌，稍后可以将其本身交换为真正的JWT令牌，但我认为这并不是我们所需要的).

因此，现在用户回到了example1.com上，并通过了身份验证！他可以发出请求，在Authentication头中传递JWT令牌，而服务器能够验证签名的JWT，因此能够识别用户。好的!

第一个问题:

如何将JWT令牌存储在客户机上？同样，也有很多关于这方面的信息，而且人们似乎都认为使用Web Storage是一种方法，而不是好的旧cookies。我们希望JWT在浏览器重新启动之间是持久的，所以让我们使用Local Storage，而不是Session Storage.

现在，用户可以重新启动浏览器，只要JWT令牌未过期，他仍将在example1.com，上进行身份验证！

另外，如果example1.com需要向我们的另一个域发出Ajax请求，我理解配置CORS将允许这样做。但是我们的主要用例不是跨域请求，它有一个单一的登录解决方案！

因此，的主要问题是:

现在，如果用户转到example2.com并希望使用他已经拥有的JWT令牌进行身份验证，那么流程应该是什么呢？Local Storage似乎不允许跨域访问，因此此时浏览器无法读取JWT令牌来向example2.com！发出请求。

应：

• 用户再次被重定向到身份验证服务器？当用户为example1.com，进行身份验证时，身份验证服务器可能已经为用户设置了cookie，因此example2.com的新身份验证请求可以使用该cookie来查看用户已经过身份验证，并立即使用相同的JWT令牌将用户重定向回example2.com？
• 或者浏览器可以在example2.com，上访问JWT令牌而不必再次访问身份验证服务器？我知道有交叉存储解决方案，但它们被广泛使用吗？它们是否是跨域SSO环境的建议解决方案？

我们不想要任何花哨的东西，我们会对最常用的解决方案感到满意！

Answer 1

应该再次将用户重定向到身份验证服务器，并获得一个新的令牌(JWT)，该令牌是example2.com专门针对的令牌。这就是OpenID连接和其他跨域联邦SSO协议的工作方式。

Answer 2

当用户未登录请求凭据并发出新的身份验证令牌时，将用户重定向到中央身份验证服务是使用oauth2或OpenId Connect等著名协议的单一登录系统中常见的场景。

但是，当该模式跨域使用时，的主要缺点是用户在导航到其他域时将被重定向和身份验证，这是由于相同的原点策略：访问令牌不能在域之间共享(example2.com不能访问example1.com的数据)，因此目标域将用户视为未经身份验证的用户，将用户重定向到中心SSO服务。

为了防止身份验证服务重新请求凭据，通常使用会话cookie (而不是访问令牌)，但是有一种技术可以使用浏览器本地存储/cookie和指向中间域sso.example.com的iframe跨域共享数据。

1. 若要在example1.com中对用户进行身份验证，请将其重定向到sso.example.com中的身份验证服务器，在身份验证后发出JWT，并将其存储在此域中的localStorage中。之后，将用户重定向到源域example1.com
2. 在example2.com中创建一个指向sso.example.com的iframe。sso.example.com中的iframe读取JWT令牌并向父页发送消息。
3. 父页接收消息并获取附加的令牌，并继续使用SSO流。

相同的原点策略没有问题，因为sso.example.com可以访问它的localStorage，并且如果源域和目标域相互识别，则允许iframe和父页面之间的通信(参见http://blog.teamtreehouse.com/cross-domain-messaging-with-postmessage)。

为了简化开发，我们最近在 https://github.com/Aralink/ssojwt上发布了一个带有JWT的跨域SSO。

该方法与SSO流完全兼容。这只是一种无需重定向的共享身份验证令牌的方法，并且在域联合时避免不必要的登录。

Answer 3

不确定这是否回答了您的问题，但如果您的主要目标是单点登录，我认为一个简单的反向代理将解决您的问题(至少跨域存储问题)。

所以example1.com example2.com

就会变成

example.com/example1 1

example.com/example2 2

(从用户的角度来看，这通常更干净)

如果这不是一个选项，您可能必须设置，以便当用户在一个域中进行身份验证时，它也使用AJAX/隐藏iframes来创建与其他域的身份验证(如果必须的话，可以通过url发送一个时间令牌)。

如果这不是一种选择，那么您可能不得不求助于username+pin，因为浏览器对跨域交互越来越严格。