在 API 网关级别与在单个微服务级别解码 OAuth2 JWT [英] Decoding OAuth2 JWT at API Gateway level vs at individual microservice level

问题描述

我使用 Spring Boot 1.5.x + OAuth2 和 JWT 开发了一组微服务(资源服务器).现在每个微服务都使用 Spring Security 进行保护，即 JWT 访问令牌在单个资源服务器级别进行验证.API Gateway 没有适当的 Spring Security，因此它只是将请求路由到适当的服务器并将身份验证标头传播到下游服务.

I have developed a set of microservices (resource servers) using Spring Boot 1.5.x + OAuth2 with JWT. Right now each microservice is protected using Spring Security i.e. JWT access token is verified at individual resource server level. API Gateway does not have spring security in place, so it just routes the requests to appropriate server and propagates the authentication headers to downstream services.

我想知道与仅在 API 网关级别验证 AccessToken 的设置相比，此设置是否有任何缺点.或者这只是一个意见问题?在 API 网关级别保持安全性是不是打破了松散耦合的原则，因为每个微服务可能会更好地理解给定用户在其自身上下文中的角色?

I wanted to know if there are any disadvantages of this setup compared to the one where AccessToken is verified at API gateway level only. Or is it just a matter of opinion? Doesn't keeping security at API Gateway level breaks principle of loose coupling, because each microservice may better understand the role of a given user in its own context?

推荐答案

API 管理可以对您的 JWT 进行小规模检查(早期失败)，但您的微服务是唯一可以真正管理所有安全内容的微服务！

API management can do a small check on your JWT (fail early), BUT your microservices are the only one that can really manage all the security stuff !

如果您仅在 api 管理上设置安全性，则意味着可以访问您网络的人将能够在未经身份验证的情况下将请求推送到您的 API.您将无法记录谁在做什么.最后，如果您需要设置某种ACL，这是不可能的(当您要求列出订单时，您只能列出您的订单).

If you set security only on api management it means that someone that can access your network will be able to push request to your API unauthenticated. You will not be able to log who do what. And finally, if you need to set some kind of ACL, it will not be possible (When you ask to list orders, you can only list YOUR order).

也许您会考虑在 api 管理层解码您的 JWT，并将带有用户名的标头推送到您的后端，以防止我上面提到的所有事情，但我认为这不是一个很好的做法.

Perhaps you will think of decoding your JWT on the api management layers and push a header with user name to your backend to prevent all the thing I spoke about above, but I think it is not really a good practice.

首先，访问网络意味着我可以成为任何人.那么 JWT 不仅仅是一个用户名.例如，也许您在身份验证层上使用范围.(范围读取订单/范围修改订单/范围删除订单).这对于限制应用程序可以做什么(在 client_id 级别)或用户接受给应用程序的内容(范围共享电子邮件...)很有用.对于后台的这个 JWT 是强制性的.

First, access to network will means I'm able to be anybody. Then JWT is much more than just a username. For instance, perhaps you use scope on your authentication layers. ( scope read orders / scope modify orders / scope delete orders). This is useful to restrict what an application can do (either at client_id level) or what a user accept to give to the application ( scope share email ...). For this JWT on the backoffice is mandatory.

好的，您可以像用户名一样在 api 管理中提取数据并将特定的标头放在调用后端，但真的吗?为什么要做具体的东西?带有 JWT 的 oauth2 可以为您做到这一点.

Ok you can do like username and extract data on api management and put specific headers to call backend, but really ? why do specific stuff ? oauth2 with JWT can do this for you.

这篇关于在 API 网关级别与在单个微服务级别解码 OAuth2 JWT的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！