首页 > 解决方案 > 如何在域之间传递 JWT 会话令牌?

问题描述

我想在我的应用程序中支持这种情况:

  1. 用户访问标准应用程序 URL https://app.example.com/
  2. 用户登录并从服务器接收 JWT 令牌,以维护登录会话
  3. 应用程序确定用户帐户分配了自定义域
  4. 应用重定向到自定义域https://custom.customer.com/
  5. 用户保持登录状态,无需重新登录

第 5 步是唯一的困难。有没有人对如何安全地实现这一点有任何建议?我已经看到了将 JWT 作为重定向中的参数传递的建议,但这对我来说似乎非常不安全。

我正在考虑一种选择,它可能至少更安全......服务器可以创建一次性“转移”令牌。这将在重定向 URL 中传递,新 URL 处的(相同)应用程序可以将其传递给服务器以获取 JWT。对此有什么想法?

谢谢。

标签: securityjwt

解决方案


出于多种原因,您不应在 url 中传递实际的身份验证令牌 (jwt)。敏感数据不应出现在网址中。

传递一次性令牌以交换身份验证令牌更安全一些,但您可以使其纯粹无状态或一次性,但不能两者兼而有之,因为您必须记住使用过的令牌。没关系,只是要考虑一下。此外,如果您可以在请求正文或标头中传递它,则应该(例如,发布请求将其放在正文而不是 url 中)。

但是,如果您这样做,您就是在重新发明单点登录。您需要的东西已经以多种不同的形式提供,最显着的是 OIDC 和 SAML。在更类似于最佳实践的架构中,您将拥有一个登录端点,该端点将充当身份验证提供者(例如 OIDC 提供者)。这将发布消费者(OIDC 术语中的依赖方,这些基本上是您的应用程序)可以直接使用或根据从身份提供者收到的令牌进行自己的会话的身份验证令牌。

在授权代码流的情况下,它看起来像

  1. 用户访问 app1,但未登录(没有有效的令牌或会话)
  2. 用户被重定向到登录服务器,在那里他登录并使用身份验证代码重定向回 app1
  3. 后台的 app1 可以将代码交换为您可以在后端使用来模拟用户的令牌,因此每个后端组件都可以确定用户是谁,并且在此步骤中 app1 可以为用户创建一个普通的旧会话,如果它想要
  4. 在随后的请求中,用户将已经拥有会话(或 id 令牌)
  5. 当用户访问 app2 时,根据您选择的确切流程,客户端要么已经有一个可以发送到 app2 的 id 令牌,要么将被重定向到登录服务器,但用户已经登录了,所以从用户的角度来看,这一切都是透明的,app2 可以正常工作。

上述的一个主要好处是它是一种标准方法,有经过充分测试的流程和现成的组件可供您使用,并且可以合理地保证它们是安全的。另一个好处是所有组件都是可替换的,您可以相对轻松地切换到另一个身份提供者(您可以从许多选项中进行选择,包括开源选项或非常便宜的托管选项),并且依赖方(应用程序)也将很容易和标准制作。


推荐阅读