Hello, I am working on a multi-tenant system where...

# server

[Irfan]

Hello,
I am working on a multi-tenant system where users can belong to multiple tenants simultaneously. This results in a many-to-many relationship between users and tenants, with roles and policies varying per tenant. During authentication, an access token is generated containing the user's roles and policies for each tenant. However, due to the large number of tenants and roles/policies, the token payload can grow significantly, potentially leading to inefficiencies in transmission, and authorization performance. The challenge is to manage this token size while ensuring efficient authorization.
Possible solutions that i am considering are -
1. Storing only a reference to the user's tenants in the token (e.g., user ID, tenant IDs), and dynamically fetching roles and policies for each tenant during reosurce authorization. But that would involve db calls at each authorization request which seems inefficient.
2. Storing only minimal claims (e.g., user ID, tenant ID) in the token and dynamically loading roles/policies during resource authorization from a cache which involves loading polices/roles in cache on successful authentication and invalidating it on logout.
3. Using rule engine during authorisation which i am not very keen about.
This doesn’t seem like an uncommon problem, so I’m here to seek suggestions and recommendations.

[dave]

Consider segmenting the users by "team" - eg. myteam.slack.com and myteam2.slack.com,.. this way you can have different cookies/auth per team site and reduce the size of each token.

Otherwise, just use a redis/memcache to store the tokens (encrypted OFC) and load the correct one based on which team they are accessing: eg. calls to https://thing.com/org/myteam vs https://thing.com/org/myteam2

[dave]

you're trading off size of token vs cost of lookup... that's only a question you can answer as to which is best based on usage patterns.

[James Richardson]

Consider separate PDP & PEP, consider what kind of token you are passing around and what it means. E.g. jwt/ macaroons / biscuits ...

[Irfan]

it's a JWT token eventually, James.