【问题标题】:Using Refresh Tokens as the Only External Access Token Given to the Client使用刷新令牌作为提供给客户端的唯一外部访问令牌
【发布时间】:2022-01-23 07:47:45
【问题描述】:

我现在正在实施基于微服务的架构。我在我的 UsersService(用于身份验证和授权的微服务)中使用FastAPI JWT Auth 来生成令牌,并在所有其他微服务中使用基本的 JWT 验证工具,以确保 JWT 是合法的(包括直接Revoked Tokens Redis 的访问权限)。

目前,我正在使用建议的架构,带有访问和刷新令牌。

我正在考虑不将 JWT 访问令牌直接暴露给客户端,而是实施一个 API 网关,在每个请求时将刷新令牌转换为 JWT .然后将 JWT 传递给内部微服务以确保边界内的安全性。

为此,客户端只需要访问刷新令牌,因为常规 JWT(生命周期极短)仅用于在内部对用户进行身份验证和授权。我计划在这些 JWT 中包含所有权限和范围信息,而刷新令牌将只有一个 user 有效负载。

我有两个问题:

  1. 这种架构会起作用吗?安全吗?
  2. 是否有推荐的 Python 框架来实现这样的 API 网关?

非常感谢! ????

【问题讨论】:

    标签: oauth-2.0 jwt microservices fastapi refresh-token


    【解决方案1】:

    这并不安全,因为将刷新令牌发送给浏览器意味着接收刷新令牌的客户端可以在不通过您的网关的情况下请求自己的访问令牌。

    更好的方法是只在客户端使用会话 cookie(我假设您的项目中有浏览器)。

    看看这个视频 https://www.youtube.com/watch?v=lEnbi4KClVw

    刷新令牌仅供请求它的客户端应用程序使用,通常将其提供给其他客户端/应用程序是一种不好的做法。

    如果您只想进行纯服务到服务的通信,您应该考虑使用客户端凭据流程,此流程不使用任何刷新令牌,也不涉及任何人类用户。也许这就是你所追求的?然后每个客户端都可以获得自己的访问令牌。

    【讨论】:

    • 感谢您的回答!您建议使用以下架构:httponly session-id -> API Gateway(内部将其转换为刷新令牌)-> Users API(内部提供网关访问令牌)-> Resources API(验证访问令牌)。我有 2 个问题: 1. 考虑到我的一些客户端是使用 requests 的 python 客户端,其中一些是移动应用程序,这个架构比我的架构更安全吗? 2. 客户端可以使用他自己的访问令牌来联系我的资源 API 有什么问题?谢谢!
    • 查看我的更新答案
    • 因此,总而言之,为了确保我正确理解您,您建议保持我的架构不变,但给客户端/浏览器 session_id(如果是浏览器,则作为 httponly cookie)而不是刷新令牌(所有刷新令牌/访问令牌的事情都只会在内部后端服务之间发生)?
    • 在你的世界里,什么是客户?它是网络浏览器吗?或桌面应用程序或只是另一种服务?是否有用户参与?我认为,如果你能澄清这一点,那会很有帮助。
    • 在我的世界中,客户端是最终用户的客户端应用程序——它可以是运行 React 应用程序的浏览器,也可以是移动应用程序、桌面应用程序等。我想要防止伪装成客户端访问后端服务的未经授权的功能的攻击者,通过强制他只能通过 API 网关访问它们并强制访问令牌的边界使用(以防攻击者通过获取访问权限直接访问后端服务到专用网络)。
    猜你喜欢
    • 2014-02-10
    • 2017-05-01
    • 2016-03-22
    • 2020-06-01
    • 2019-05-24
    • 2019-01-08
    • 2019-06-29
    • 2014-07-18
    • 2017-12-07
    相关资源
    最近更新 更多