这取决于整体架构和每个服务的扩展要求。

专用外部API网关微服务

你可以创建一个专用的外部API网关微服务，它只负责连接到外部API来处理oauth2流/访问令牌/刷新令牌，并将所有内容保存在该服务的内存中。该特定服务的扩展需求很可能与微服务环境的其他部分不同。（您可以根据外部授权服务器的速率限制来限制缩放）。
然后，该微服务可以将其功能公开给您的环境中可能有更大扩展需求的其他微服务。
优点是所有内容都包含在一个微服务中，不需要存储。您可以通过设置缩放来确保不对外部授权服务器进行速率限制。
它还将提供一个很好的层来引入缓存，并提供一个很好的抽象级别

在安全存储中存储令牌

可以设置一个安全的全局存储机制，以便每个需要访问该外部API的服务都可以获得访问令牌并调用API，但这通常不是大多数oauth2客户端的工作方式（在Spring中不是）。通常不使用刷新/访问令牌来“引导”oauth2流，而是使用支持的oauth2流之一来引导它。
您需要妥善保管此存储。使用云提供的机制，如AWS上的安全SSM参数存储，或自己加密令牌。您还需要协调刷新访问令牌并将它们更新到存储中，确保它们足够快地分发到所有服务。
这有时会被证明是一个麻烦和基础设施的影响，而不是仅仅去前面概述的专用外部API网关原则。

存储代币的最佳位置是什么？
JWT应该存储在一个高度可用和可扩展的数据存储中，所有微服务都可以访问。最好的解决方案是使用集中式授权服务器生成一致且安全的JWT。
redis？数据库？
Redis和databases（如PostgreSQL、MySQL或MongoDB）都是存储令牌的好选择。但是，数据存储的选择取决于系统的特定要求。
Redis可以存储过期时间较短的JWT，因为Redis是内存中的数据存储
Databases（如PostgreSQL，MySQL或MongoDB）可以存储JWT更长的时间，因为它们是Redis的持久性存储。
将JWT存储在云上的微服务中的最佳实践是什么？
如果我们谈论的是云，我建议使用基于云的托管数据存储，如AWS DynamoDB或Google Cloud Firestore。因为它们提供了高可用性和自动扩展。此外，最好使用Kubernetes-native data stores，如ETCD或ZooKeeper。