我有3种服务（实际上更多）：
和客户端（网络浏览器）。
我将session_id，access_token和refersh_token存储在用户的Web浏览器的cookie中。用户进入Auth服务，登录并获取这些令牌。将他的网络浏览器重定向到Frontend之后。
前端和资源服务无法验证令牌，因为它们对此一无所知，因此必须向Auth服务发出请求。
当前情况：
用户（网络浏览器）向Frontend服务发送请求，Frontend向Auth服务发送请求以验证access_token。如果无效，则前端会使用refresh_token发送刷新令牌的请求。
如果前端需要访问Resource服务以处理请求，则前端将其client_id和access_token发送到Resource服务。资源服务也向Auth服务发送请求以验证access_token。
我的想法正确吗？还是它的架构更简单？
P.S。。所有服务都使用RESTful体系结构。
答案 0 :(得分：1)
OAuth讨论了令牌的交换方式。您刚才所说的使用隐式授予似乎有点荒谬，因为隐式授予的安全性稍差一些，您可能会考虑选择授权流程。
除此之外，在微服务中，当您有许多服务并且一个用户请求通过许多下游服务时，在每一步使用auth provider验证令牌可能会成为瓶颈。
您可以通过多种方法跳过对身份验证服务器的调用，而无需进行显式调用即可仍然验证令牌的安全性。 一种方法是利用JWT。这些令牌由Auth提供者签名，您的服务具有密钥，可以帮助您验证令牌是否已按此方式进行了修改，令牌本身具有确保令牌有效性所需的所有信息，例如到期时间，预定的受众群体，客户，角色等。
登录后，您将获得AT和RT。可以将AT传递到下游进行身份验证和授权，并且可以在AT过期时使用RT。 您只需要在登录时和需要刷新令牌时与身份验证提供者联系。
您可以阅读有关带有JWT和OIDC的JWT OAuth2.0的更多信息，以获取有关它的更多信息