Security openid connect 2.0和在仅http cookie中设置身份验证JWT

由于本地存储和会话存储都可以通过JavaScript访问，因此最好不要将身份验证JWT存储在其中任何一个中，以避免XSS攻击

由于OpenIDConnect 2.0是在一个单独的域上执行的，我们如何设置一个包含经过身份验证的JWT的服务器端HTTP专用cookie

我猜是这样的：

用户进入您的网站，然后单击“登录”

用户将被重定向到第三方OpenID connect 2.0提供程序

用户登录，现在被重定向到您选择的路径www.example.com/myredirectlogin

然后，当重定向到达我的路由上并传入URI中的JWT令牌时，用户的浏览器发出get请求

然后，服务器使用提供者提供的公钥通过非对称算法验证JWT

然后，服务器返回一个服务器端仅HTTP的cookie，其值为JWT，客户端对JWT没有任何记忆，因为JWT只存在于URI中，不存储在其他任何地方

我的问题是：以上是安全处理OpenIDConnect 2.0流的正确过程吗？

我假设您说的“身份验证JWT”是指“Id令牌”，因为这是OpenIDConnect所需的唯一JWT

---

中列出了OpenID connect支持的所有流。如果您想登录到授权服务器并对一个单独的站点进行身份验证，那么您通常会使用“授权代码”流，它根本不会将ID令牌发送到浏览器。OpenID connect定义了其他流，但没有一个提到将ID令牌存储在cookie中-如何在客户端（您要验证的站点）和浏览器之间维护会话与验证用户是一个单独的问题。

我在授权代码流中找到了答案：

步骤清单

OAuth 2.0和OIDC授权代码流

用户点击您网站的登录路径

用户被重定向到具有正确租户id的身份提供程序

用户已通过身份验证，并通过查询参数中的访问令牌重定向到您的回调路由，即&access_code=23424SDFKLJSAK

使用查询参数中的访问令牌在回调路由的web服务器上执行get请求

然后，此回调get路由应进行post调用，以从提供商（即azure b2c）检索实际的JWTidentity令牌，并将访问令牌作为请求的一部分添加为查询参数或post of body

然后，提供商（Azure B2C）将使用标识JWT令牌进行响应，我们将以仅HTTP会话cookie的形式将该令牌发送回用户的浏览器，这样用户现在就可以在所有浏览器选项卡之间进行SSOAD，cookie将随每个请求自动发送，并受到xss的保护