I'm now implementing a microservices-based architecture. I'm using FastAPI JWT Auth in my UsersService (the microservice for authentication and authorization) to generate the tokens, and basic JWT validation tools in every other microservice, to ensure that the JWT is legit (including direct access to the Revoked Tokens Redis on every one of them).
Currently, I'm using the suggested architecture, with access and refresh tokens.
I'm considering not exposing the JWT access tokens directly to the clients, and instead, implementing an API gateway that will convert the refresh tokens to JWTs on every request. The JWTs will be passed then to the internal microservices to ensure in-bounds security.
To do this, the client only needs access to the refresh tokens, as the regular JWTs (that will have an extremely short lifespan) are only used to authenticate and authorize the user internally. I plan to include all the permissions and scope information inside those JWTs, while the refresh token will only have a user payload.
I have 2 questions:
Thank you very much! 😄
That is not secure, as giving out the refresh token to the browser means that the client receiving the refresh token can ask for their own access token without going through your gateway.
A better approach is to only use a session cookie with the client (I assume a browser in your project).
Do take a look at this video https://www.youtube.com/watch?v=lEnbi4KClVw
The refresh token is only meant to be used by the client application requesting it and it is a bad practice in general to give it out to other clients/applications.
If you want to just have pure service-to-service communication ,you should look at using the client credentials flow, this flow does not use any refresh tokens and does not involve any human user. Perhaps that is what you are after? Then each client can get its own access token.