I have a problematic and a potential solution and i'm wondering if it's a good solution or if a better way of doing things exists.
I have an API A called by a frontend with a JWT token.
If the service doesn't have the solution I would like this service to fetch the solution from another API B.

Is it a good idea to forward the JTW token I received from the Front User and authenticate to the API B as this user to request my data (knowing that the JWT may carry useful information) ?
Should I maybe drop the JWT and authenticate in a different way to this API ?
Is there an industry standard for theses kinds of things or good pratice?

CodePudding user response：

JWT access tokens are designed to be forwarded between APIs. Doing so maintains an auditable user identity. Each API then verifies the JWT signature, issuer, audience, scopes and claims. This is sometimes called a zero trust API architecture - but there are caveats.

SCOPES

Design these in terms of areas of business data. Eg client has scopes orders shipping and calls an Orders API. The Orders API can then forward the JWT to the Shipping API. Each API must check for the scopes it needs.

SAME TRUST LEVEL

As always, you need to think about threats. My above recommendations are for APIs split into microservices, often for technical reasons, eg smaller code sizes and multiple development teams.

DIFFERENT TRUST LEVELS

Consider forwarding a JWT to a Shipping API in a subdivision of a large company. You may not trust to give them the orders scope. In that case, use token exchange to get a new token with only the shipping scope, then forward that to the upstream API.

SUMMARY

Always aim to forward a JWT that maintains an auditable user identity. Use scopes as one ingredient to ensure least privilege. Also evaluate threats, to prevent potential exploits.