微服务控制器的权威性如何
我正在开发一个新的分布式应用程序。我已经有一些操作微服务，而且效果很好。我现在正在实施身份验证/授权，并且有严重的疑问。
1.-首先使用JWT MicroService进行认证并获得令牌。该令牌包含指示用户可以访问哪些属性的主张。
2.-这个令牌的到期3天。因此，当我向微服务提出请求时，我将附加令牌。
3.-但是，当请求到达任何微服务控制器时，我如何确认令牌有效并且用户拥有此控制器功能的许可？还是自令牌生成以来的索赔发生了变化？
是否有必要向JWT微服务提出另一个请求以验证它？
是否有一种更有效的方法来验证微服务控制器中每个用户的权限。我不必再次向JWT微服务发送另一个请求。
我读到API网关有时会作为接入点实现。如果是这样，可以在API网关中验证用户访问权限吗？哪种技术是最佳的（骆驼，春云）？为此，我补充说，我们将这些微服务部署在Google Cloud Kubernetes（GKE）中。
如果在微服务方面有经验的人可以启发我。
谢谢
I am developing a new distributed application. I already have some operational microservice and it works fine. I am now implementing authentication/authorization and I have serious doubts.
1.- First I authenticate with the JWT microservice and obtain a token. This token contains the claims that indicate which properties that user has access to.
2.- This token has an expiration of 3 days. So when I make a request to a microservice I attach the token.
3.- However, when the request reaches any microservice controllers, how do I confirm that the token is valid and the user has permisions for this controller function? or if the claims have changed since the token was generated ?
Is it necessary to make another request to the JWT microservice to validate it?
Is there a more efficient way to validate each user's permissions in microservice controllers. I would like to not have to send another request to the JWT microservice again.
I have read that an API Gateway is sometimes implemented as an access point. If so, could the user access permissions be validated in the API Gateway? What technology is the most optimal (Camel, Spring Cloud)? To this, I add that we are deploying these microservices in Google Cloud Kubernetes (GKE).
If someone who has experience in microservices can enlighten me.
Thank you
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
令牌验证有两种主要方法：本地和RPC调用。
本地更受欢迎。这是AWS，GCLOUD和Azure采用的方法。令牌本身具有所有必需的信息 - 谁是用户，什么是权限。和令牌已签名。
当在服务（或API网关）上收到这种类型的令牌时，该服务可以通过检查签名和到期来在本地验证该令牌。该服务基于代币的验证内容，决定该做什么。
值得一提的是，这种方法不允许撤销令牌。很少有解决方法，但是大多数解决方案都依赖于较短的代币并发出刷新令牌。 （请让我知道这是否是话题的话题）。
拥有本地验证还开放了一种有趣的限制范围的方法 - 当系统发出访问令牌时，令牌可以有限的访问权限 - 用户可以做的任何事情的子集。这是限制风险的好功能。
另一种方法是调用一些内部服务以进行令牌验证。这似乎更容易理解方法，但纯粹是缩放的。
还有一件事要注意：在API网关上或服务本身上，应在哪里检查令牌。传统上，曾经检查边界 - API网关的访问。如今，公司将转移到零信任体系结构（这意味着在每项服务上都可以验证访问权限 - 没有隐含的信任。
There are two major approaches to token validation: local and rpc call.
Local is way more popular. This is the approach AWS, GCloud and Azure take. The token itself has all required information - who is the user, what are permissions. And the token is signed.
When this type of token is received on a service (or api gateway), the service can validate the token locally - by checking signature and expiration. Base on validated content of a token, the service decides what to do.
It is worth mentioning, that this approach does not allow token to be revoked. There are few workaround, but most solutions just rely on shorter lived token and issue a refresh token. (please, let me know if this is topic to talk more).
Having local validation also opens an interesting approach to limiting scope - when a system issues an access token, the token can have limited access - subset of whatever a user can do. This is nice feature to limit risks.
The other method is to call some internal service for token validation. This seems like easier to understand approach, but it scales purely.
One more thing to note: where token should be checked - on api gateway or on a service itself. Traditionally, access used to be checked on boundaries - api gateway in your case. These days, companies move to Zero Trust Architecture - which means access is verified on every service - there is no implicit trust.