使用 JWT 进行跨域身份验证的单点登录流程 [英] Single sign-on flow using JWT for cross domain authentication

问题描述

网络上有很多关于使用 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 环境的建议解决方案吗?

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

解决方案

用户应该被再次重定向到身份验证服务器并获得一个新的令牌 (JWT)，一个专门针对 example2.com 的令牌.这就是 OpenID Connect 和任何其他跨域联合 SSO 协议的工作原理.

There is a lot of information on the web about using JWT (Json Web Token) for authentication. But I still didn't find a clear explanation of what the flow should be when using JWT tokens for a single sign-on solution in a multiple domains environment.

I work for a company which has a lot of sites on different hosts. Let's use example1.com and example2.com. We need a single sign-on solution, which means if a user authenticates on example1.com, we want him to also be authenticated on example2.com, automatically.

Using the OpenId Connect flow, I understand that the user who wants to authenticate on example1.com will first be redirected to the authentication server (or OP : "OpenId Provider"). The user authenticates on that server which then redirects him back to the original example1.com site with a signed JWT token. (I understand there is another flow which returns an intermediate token that itself can be exchanged for the real JWT token later on, but I don't think this is required for us)...

So now the user is back on example1.com and is authenticated! He can make requests, passing the JWT token in a Authentication header and the server is able to verify the signed JWT and therefore is able to identify the user. Nice!

First question :

How should the JWT token be stored on the client? There is, again, a lot of information about this, and people seem to agree that using Web Storage is the way to go rather than good old cookies. We want the JWT to be persistent between browser restarts so let's use Local Storage, not Session Storage...

Now the user can restart his browser and he will still be authenticated on example1.com, as long as the JWT token is not expired!

Also, if example1.com needs to make an Ajax request to another of our domains, I understand configuring CORS would allow that. But our main use case is not cross-domain requests, it's having a single sign-on solution!

Therefore, the main question :

Now, what should the flow be, if the user goes to example2.com and we want him to be authenticated, using the JWT token he already has? Local Storage doesn't seem to allow cross-domain access so at this point the browser can't read the JWT token to make requests to example2.com!

Should :

• The user be redirected to the authentication server again? When the user authenticated for example1.com, the authentication server may have set a cookie on the user so this new authentication request for example2.com could use that cookie to see that the user is already authenticated and immediately redirects him back to example2.com with the same JWT token?
• Or can the browser, on example2.com, access the JWT token without having to go to the authentication server again? I see there are cross-storage solutions, but are those widely used? Are they the suggested solution to a cross domain SSO environment?

We don't want anything fancy, we would be happy with the mostly used solution!

解决方案

The user should be redirected to the authentication server again and get a new token (JWT), one that is specifically targeted for example2.com. This is how OpenID Connect and any other cross-domain federated SSO protocol works.

这篇关于使用 JWT 进行跨域身份验证的单点登录流程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！