Best practice for securing API's in micro services


I want to validate what I think / implemented authorization in microservices.
Don’t want to detail about our architecture, in short we have a role for each API and we add roles to groups and assign a group to user. When you user gets the brearer token, he gets the list of ROLES in the token. It works great until the token size limit exceeded, sometimes it even goes to 30KB depends on the number of ROLES that the user will have. I think this is not a good practice. Anyone implemented OAUTH in their microservice environment successfully if so whats the strategy you follow to secure API and if you have more than 1000’s of API’s.

Thanks in advance

Possible tracks to reduce the size of the JWT:

  • invert the call: receive the JWT, extract the id of the user, and then ask the identity server for the presence or not of a role. Pushed to the extreme, you can have a minimal token that contains no other info that one identifier for the subject, but otherwise it can contain some useful stuff but not all the roles. It’s a particular form of optimization, it runs a bit contrary to the philosophy of JWT, and requires a link to user base.
  • JWT dedicated to a particular micro-service, or a set of micro-services. When service A need to call service B, first it calls the authz server to exchange its A-token for a B-token. B-token contains only claims that are of interest to service B. This is more pure OAuth, as OAuth recommends that a JWT has a precise audience (“aud” claim). It can be modified a bit, you can group your micro-services into clusters that share the same audience and claims. ← this one is my favorite, but Keycloak is not a good token exchange server.
  • organize your permissions model differently. This is an information modelisation effort, dependent on your context.

I’m interested if you can share the solution that you implemented.


Somehow missed the response. I like first point to request OAUTH for scopes / roles etc. We are also looking at OPA (open policy agent) to implement it as a side car pattern. But not sure how complex that solution going to be to implement in our stack.
Will update here when we decide on it

Actually that should not change my reply :slight_smile:

If using OPA, then there should be 2 contact points with Keycloak, both using OIDC (nothing Keycloak-specific I mean).

  • JWT containing claims. This means agreement between Keycloak who maps the claims and OPA who reads them to resolve policies
  • userinfo OIDC endpoint, to get any required claims from Keycloak that are not in the JWT. For example, the humongous number of roles