Achieving Multitenancy with an External Identity Provider

Its best practice to put role claims in the JWT and you shouldn't have to worry about role claims bloating the JWT.

However! to keep that from happening you have to be able to separate out apps and tenants of apps in the auth system.

ie I have to be able to sign in as person X, to app Y, acting as company Z and get a role set which is limited to those parameters.

Otherwise you will end up having to concatenate Y and Z parameters into the roles eg.

AdminTeamsMicrosoft
AdminExcelMeta

Are different "Admin" roles and now a users roles will be multiplied by the number of apps and tenants they are associated with, which could be enough to break cookie size limits or provider limits (eg OKTA role numbers)

The other problem with using the "external" ID provider for roles is if you want users of the apps to be able to manage their own permissions. To do so they will need to log into the auth system and select roles. Obviously that login and role management UI will have to be limited to the apps, users and tenants assigned to that user.

Before making a decision you have to understand if your Auth provider supports these features.

If it doesn't, then you will be forced to have a second auth layer where you fetch the roles specific to the tenant or app. This might be passed around as another jwt though.

What you are describing is fine-grained access. While some of it can be expressed as claims, the bulk should be expressed in a rules engine using 'policies' (in the broad sense). This is an area known as externalized authorization or attribute-based access control (ABAC). See NIST's publication.

The architecture is as follows:

There are many frameworks that implement this for you in a flexible way:

• XACML
• ALFA (Wikipedia)
• Open Policy Agent
• AWS Cedar

Goal: keep your claims to a minimum and use the policies to convey access control.

To start off, you don't mention Oauth2 here but I guess that's the context of this question. You mention Auth0 which has some good resources for navigating this space. I'm not sure that link helps you here specifically but I find that it helps communication a lot to understand that OAuth2 approaches vary.

We are designing a backend system for a large platform where users can interact with multiple products on behalf of different companies.

This is a little unclear to me but I understand this to mean you are supporting multiple products/services that can be accessed by users from different companies. That is, you (i.e., your employer) own and control all these products. If that's not right, please let me know.

To further check my understanding, you are definitely using an identity provider and JWTs for authentication (authn) and are trying to figure out whether and to what extent you want to use them for authorizations (authz).

If my understanding that you control all the resources, this gives you a lot of flexibility. You could simply have the JWT tell you who the caller is, and each product/service/resource would then be responsible for managing whether that user is authorized to use the service and what rights they have. If each service had it's own authorization approach, this makes a lot of sense. Of course, this also means you have more opportunities to make mistakes. You also say:

This is simpler to implement at first but adds complexity in the long run, as every component would depend on the authorization server. Caching mechanisms would likely be necessary to prevent overwhelming it with requests.

Which tells me that you have a centralized source of authorization rules.

The identity provider would need to know the user’s state in our system.

This is an interesting way to put this. The identity provider would need to know what permissions a given user has. If that's the 'state' that you are referencing, there are standard ways to manage that with identity providers with e.g., LDAP. Referencing Auth0 (they have decent docs, not an endorsement) again, they provide an AD/LDAP connector. I would expect any major player in this space to offer something similar in functionality. But if your authorization is stored in a proprietary way, that would be on you to bridge that to the provider.

If you decide it is just not worth the effort to sync authz with the identity provider, handling it directly at your authorization server isn't tremendously challenging. Your authz host could cache the responses itself, of you could cache them in intermediaries. You would be responsible for making that secure and you should not take responsibility lightly. You don't specify the volume of requests but would guess that caching at the user level or user/system level should resolve your concerns.

The issue with caching that you must consider is how long a cached authorization should be valid. It so happens that this is the same question you will need to answer if you use the identity provider to manage authorizations. That is, claims encoded on the token or in a cache will typically be valid for the lifetime of the access token. A good way to think about this is: if a user had access stripped away, what's the maximum acceptable time before that removal of access is enforced? Often a refresh token is used to allow access tokens to expire more quickly than you require reauthentication.