授权代码流Jwt通常用于对人类用户进行认证。客户端凭证流Jwt通常用于认证服务器客户端。我们对这两种流使用相同的oauth 2服务器。然而,有些服务不喜欢人类用户使用它们的jwt来调用它们。那么,什么是防止授权代码流Jwt被用于验证对仅后端到后端服务的调用的最佳实践呢?
stszievb1#
我的2分:如果您的后端服务部署在同一个集群或网络中,并且该服务仅支持后端到后端,则不应向外界公开/发布其API。这种方法不需要修改代码,但可以在基础架构(网络、防火墙)层完成。如果您的后端服务部署在不同的集群/网络中,那么您应该在应用程序层(您的后端代码)处理不支持Authorization-code-flow
Authorization-code-flow
a0x5cqrl2#
Tuan LE CONG提到,您可以在基础架构级别限制访问-您可以确保拥有用户令牌的服务无法调用那些需要客户端凭据令牌的服务。另一种方法是基于访问令牌做出授权决策。JWT访问令牌由声明组成,在每个令牌中,您将找到一个sub声明。这标识了令牌的主题。对于用户令牌(使用授权代码流创建的那些),您将拥有用户的ID、电子邮件或sub声明中的类似信息。(用客户端凭证创建的流)、您将获得服务的ID(OAuth客户端ID)。您可以拒绝任何不包含有效客户端ID的请求。此验证可以由服务本身或API网关执行。
sub
2条答案
按热度按时间stszievb1#
我的2分:
如果您的后端服务部署在同一个集群或网络中,并且该服务仅支持后端到后端,则不应向外界公开/发布其API。这种方法不需要修改代码,但可以在基础架构(网络、防火墙)层完成。
如果您的后端服务部署在不同的集群/网络中,那么您应该在应用程序层(您的后端代码)处理不支持
Authorization-code-flow
a0x5cqrl2#
Tuan LE CONG提到,您可以在基础架构级别限制访问-您可以确保拥有用户令牌的服务无法调用那些需要客户端凭据令牌的服务。
另一种方法是基于访问令牌做出授权决策。JWT访问令牌由声明组成,在每个令牌中,您将找到一个
sub
声明。这标识了令牌的主题。对于用户令牌(使用授权代码流创建的那些),您将拥有用户的ID、电子邮件或sub
声明中的类似信息。(用客户端凭证创建的流)、您将获得服务的ID(OAuth客户端ID)。您可以拒绝任何不包含有效客户端ID的请求。此验证可以由服务本身或API网关执行。