如何跨不同的API验证JSON Web令牌(JWT)? [英] How to authenticate JSON web tokens (JWT) across different APIs?

问题描述

我已经基于PHP Slim框架创建了一个Rest API，该框架使用JSON Web令牌(JWT)对访问进行身份验证和授权.

I've created a Rest API based on the PHP Slim framework which uses JSON Web Tokens (JWT) to authenticate and authorize access.

要使用API​​，客户端必须首先通过将其凭据发送到特殊的/auth/token路由进行身份验证，如果正确，该路由将返回包含允许权限列表的数字签名令牌.对API的所有后续请求都需要令牌进行身份验证和授权.这是相当标准的东西，效果很好.

To use the API the client must first authenticate themselves by sending their credentials to a special /auth/token route which if correct, returns a digitally signed token containing a list of allowed permissions. All subsequent requests to the API require the token for authentication and authorization. This is pretty standard stuff and works well.

但是现在我现在想将/auth/token服务分成其自己的微服务，以便将来我可以将其与其他API复用.

But now I now want to separate the /auth/token service into its own micro-service so I can reuse it with other APIs in the future.

问题是，由于API无法访问用于生成JWT的秘密，因此API现在将如何对JWT进行身份验证?

The problem is, how will the APIs now authenticate the JWT as they don't have access to the secret that was used to generate it?

我使用Firebase\JWT\JWT生成令牌，该令牌将被移至新的身份验证服务.然后，我使用tuupola/slim-jwt-auth中间件对每个API上接收到的令牌进行身份验证.

I use the Firebase\JWT\JWT to generate the token, which will be moved to the new auth service. And I use tuupola/slim-jwt-auth middleware to authenticate the received token on each API.

由于每个API和新的身份验证服务都将在同一主机上运行，​​因此我也许可以在它们之间共享秘密，但这是一种不好的做法.有更好的方法吗?

As each API and the new auth service will be running on the same host I could maybe share the secret between them all but this feels like bad practice. Is there a better way?

推荐答案

最好使用私钥/公钥(RSA或ECDSA算法)而不是秘密(HMAC算法)对JWT进行签名.在这种情况下，您的身份验证服务将使用私钥对JWT进行签名，而其他API将使用公钥对JWT进行验证，那么……您仍然需要向其API分配公钥，但是您可以选择.

It is better to sign JWT using private/public key (RSA or ECDSA algorithm) instead of a secret (HMAC algorithm). In that case your auth service would sign JWT with private key and other APIs would validate JWT with public key, well... you still need to distribute a public key to your APIs then, but you have options.

取决于您的体系结构，您可以查看:

Depends on your architecture, you might look at:

API网关模式

对于微服务架构，一个好的实践是使用API​​网关模式. 有关网关模式的更多信息. API网关可以验证JWT令牌，然后将请求代理到您的服务.因此，身份验证服务将使用私钥对JWT令牌进行签名，然后对API的请求将通过API网关发送. API Gateway会使用公共密钥验证令牌，因此您不会将公共密钥分发给代理后面的所有API.

For microservice architecture a good practice is to use API Gateway pattern. More about gateway pattern. API Gateway can validate JWT token and then proxy requests to your services. So auth service would sign JWT token with private key, then requests to APIs would go though API Gateway. API Gateway would validate token with public key, so you would not distribute public key to all APIs behind the proxy.

使用这种方法，您将需要一个API网关，您可以查看: express-gateway ， kong + tyk 等，也有很多从API网关获得的更多好处，而不仅仅是JWT令牌验证，如流量控制，分析，日志记录，请求和响应转换等.

With this approach your would need an API Gateway, you can look at: express-gateway, kong + jwt plugin, tyk etc, also there is much more benefits from API Gateway rather then just JWT token validation, like traffic control, analytics, logging, requests and responses transformations and so on.

秘密管理

除了API Gateway之外，您还可以查看集中式机密管理系统，例如 Hashi Vault .取决于项目/团队的规模，这可能对您的项目来说是一个过大的杀伤力.

Instead of or additionally to API Gateway you can take a look at centralised secrets management systems, like Hashi Vault. Depends on the project/team size it could be an overkill for your project.

这篇关于如何跨不同的API验证JSON Web令牌(JWT)?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！