网络上有很多有关使用JWT（Json Web Token）进行身份验证的信息。但是我仍然没有清楚地说明在多域环境中将 JWT令牌用于单点登录解决方案时的流程。
我为一家在不同主机上有很多站点的公司工作。让我们使用example1.com和example2.com。我们需要一个单一的登录解决方案，这意味着如果用户在example1.com上进行了身份验证，我们希望他也可以在example2.com上进行自动身份验证。
通过使用OpenId Connect流，我了解到要在example1.com上进行身份验证的用户将首先被重定向到身份验证服务器（或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来查看该用户是否已通过身份验证，并立即将其重定向回 example2.com。使用相同的JWT令牌？
- 还是可以在example2.com上的浏览器访问JWT令牌而不必再次进入身份验证服务器？我看到有交叉存储解决方案，但是广泛使用了吗？它们是跨域SSO环境的建议解决方案吗？
我们不需要任何花哨的东西，我们会对使用最广泛的解决方案感到满意！