How do authoritzation on microservices controllers

Viewed 126

I am developing a new distributed application. I already have some operational microservice and it works fine. I am now implementing authentication/authorization and I have serious doubts.

enter image description here

1.- First I authenticate with the JWT microservice and obtain a token. This token contains the claims that indicate which properties that user has access to.

2.- This token has an expiration of 3 days. So when I make a request to a microservice I attach the token.

3.- However, when the request reaches any microservice controllers, how do I confirm that the token is valid and the user has permisions for this controller function? or if the claims have changed since the token was generated ?

Is it necessary to make another request to the JWT microservice to validate it?

Is there a more efficient way to validate each user's permissions in microservice controllers. I would like to not have to send another request to the JWT microservice again.

I have read that an API Gateway is sometimes implemented as an access point. If so, could the user access permissions be validated in the API Gateway? What technology is the most optimal (Camel, Spring Cloud)? To this, I add that we are deploying these microservices in Google Cloud Kubernetes (GKE).

enter image description here

If someone who has experience in microservices can enlighten me.

Thank you

1 Answers

There are two major approaches to token validation: local and rpc call.

Local is way more popular. This is the approach AWS, GCloud and Azure take. The token itself has all required information - who is the user, what are permissions. And the token is signed.

When this type of token is received on a service (or api gateway), the service can validate the token locally - by checking signature and expiration. Base on validated content of a token, the service decides what to do.

It is worth mentioning, that this approach does not allow token to be revoked. There are few workaround, but most solutions just rely on shorter lived token and issue a refresh token. (please, let me know if this is topic to talk more).

Having local validation also opens an interesting approach to limiting scope - when a system issues an access token, the token can have limited access - subset of whatever a user can do. This is nice feature to limit risks.

The other method is to call some internal service for token validation. This seems like easier to understand approach, but it scales purely.

One more thing to note: where token should be checked - on api gateway or on a service itself. Traditionally, access used to be checked on boundaries - api gateway in your case. These days, companies move to Zero Trust Architecture - which means access is verified on every service - there is no implicit trust.

Related