There are several approaches for managing authentication in microservices including service to service authentication. I want to understand which approach is better.
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.
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.
CodePudding user response：
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.
CodePudding user response：
Do you really need to generate another token for your services after validating the first token? Aren't your services are private to the outer world and the only exposed entity is Gateway. The whole ecosystem of services behind the Gateway should be setup in trusted way. Therefore, once the token is validated, you don't need to pass it to downstream services.
Approach 1. Gateway each time needs to doo auth-service call to validate?
You could use the JWT instead of opaque token. Validation process could be done at the Gateway without invoking the token services.
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.
You can set the expiration time as per your requirement. Access token expiration time are usually small and in ideal cases it could vary between 15 minutes to 1 day. Expiration attribute is one of the claim of JWT. Expired token should be rejected during the validation process at the Gateway. It's client responsibility to generate the token again if expired by either following the authentication process again or by using the Refresh token if available.
Updated:
As JWTs expiration time is small, is it user-friendly to always require the client to log in again to the system, because we use JWT tokens?
Refresh tokens are available to address that concern. Refresh tokens have a longer lifetime than access tokens. Once your access token expired, client should use the refresh token to get newly access token and prompt the user for authentication process only on the expiration of refresh token.
exposing JWTs to the outside world can expose sensitive information in the JWTs
When someone has such concern about sensitive information disclosure then they can prefer JWE over JWT.