Authentication patterns in microservices

user_6350191 0
Viewed 85

There are several approaches for managing authentication in microservices including service to service authentication. I want to understand which approach is better.

  1. When a user logs in to the system auth-service call is happening and the auth-service returns an opaque token (not JWT), then each API call contains that opaque token Gateway validates the token through the auth-service generates a new JWT token for downstream services. So downstream services will not have to call auth-service each time to validate the token.

  2. From the beginning auth-service will generate a JWT token.

    2.1. Gateway will validate and pass it through downstream services and all services will use the same token

    2.2. Gateway validates and generates a new token each time, and also downstream services do the same.

Each approach has its pros and cons.

Questions:

Approach 1. Gateway each time needs to doo auth-service call to validate?

Approach 2. What will be the expiration time for JWT tokens? Who needs to handle the expirations, what token expires in between who needs to regenerate it again? JWT tokens must be short-lived, so whether it will not affect client behavior, or refresh tokens should come in the picture here.

So I am confused about which approach is good,or are there other approaches.Please advise me.

system-design microservices jwt spring-security spring
1 Answers

JWTs should be avoided to be exposed to the outside world since these could potentially include sensitive information in custom claims. Especially if you work in a large company, where you can't keep track of what ends up in different claims.

So if using opague tokens (which you should) the gateway should verify and exchange the token to a JWT that can be used internally inside your network.

All services SHOULD always be setup with zero trust in mind.

All services should if possible fetch JWKs to verify the incoming JWTs. And these JWKs should be rotated on a regular basis.

This is to avoid that if a malicious actor gets access to the internal network he shouldnt be able to do any request to any service just because he has passed the gateway.

When it comes to expiration times, these should be set by the issuer and should be kept short because one of the big problems is that its easy to issue a token, but harder to revoke one.

The flow is usually as such:

  • Client logs in and gets issued a AT (access token) and a RT (refresh token)
  • Client presents opague AT token to a service in the backend
  • Gateway exchanges the opague token for a JWT
  • Gateway passes the JWT to the service that is requested
  • The resource server validates the JWT
  • if request is denied a httpstatus of 401 is returned to the calling client
  • the client receives the 401 and then presents its refresh to the issuer that will issue a new AT token.
  • request is redone with the new AT token.
user_18401460
Related