【问题标题】:Ways of overriding the behavior of the lexik/jwt-authentication-bundle to allow n number of public keys from an external source覆盖 lexik/jwt-authentication-bundle 的行为以允许来自外部源的 n 个公钥的方法
【发布时间】:2023-01-31 20:56:17
【问题描述】:

一些背景: 我们有许多应用程序,每个应用程序都有自己的身份验证提供程序和公钥/私钥对以及它们自己的密钥轮换。 当一个新的应用程序启动或轮换其密钥时,公钥将保存在密钥库中的其他地方,以供其他应用程序获取。

我有一个 Symfony 5.4 服务,我想对来自这些应用程序的用户进行身份验证,它们提供的 JWT 在标头中包含 KID,因此流程为:

  1. 使用 JWT 接收请求
  2. 从标头获取 KID
  3. 在我们的密钥库中查找 KID 并加载公钥
  4. 验证 JWT 签名匹配。
  5. 从他们那里开始的流程正如您所期望的那样,加载 JWSUser 等,并且防火墙按其应有的方式工作。

    我可以只获取密钥存储并为其生成一个大的配置文件,但这在运行时并不理想,并且通过查看代码它会尝试每个替代密钥,直到验证成功,并且无法扩展。

    据我所知,我有两个选择:

    1. 用我自己的扩展 Lexik\Bundle\JWTAuthenticationBundle\Services\JWSProvider\LcobucciJWSProvider 并覆盖验证方法以首先找到正确的公钥。

    2. 创建我自己的实现 JWSProviderInterface 的 JWSProvider 并重现大部分逻辑,除了它如何获取用于验证的公钥。

      显然,在这两个中,#1 看起来最简单,但是 LcobucciJWSProvider 在文档块中被标记为@final,即使类本身没有使用 final 关键字,所以它可能不应该被扩展。

      我认为这是我的两个选择是否正确?

      我最初希望我可以只实现我自己的密钥加载器,但看起来他们永远不会收到有关所请求密钥的信息,即使需要公钥或私钥。

【问题讨论】:

    标签: lexikjwtauthbundle


    【解决方案1】:

    我正在研究类似的东西......

    我正在使用 API 平台来提供服务器 2 服务器 API,并且不需要 JWTAuthenticationBundle 提供的任何用户名/密码身份验证。 相反,我想要每个客户一个证书。

    你选择了什么实现?

    【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2022-11-13
    • 2022-10-14
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-09-24
    • 2022-01-11
    • 1970-01-01
    相关资源
    最近更新 更多