[keycloak-user] Scalable architecture for multi-tenant (multi-resource) auth solution

[Yuriy Yunikov]

We're evaluating two different architectures for setting up KeyCloak to
allow users to grant access to other users and third parties to tenants
within our system.

I'm looking for experienced feedback on these to try and save some time
with experimentation.

## First approach *Dynamic Client Registration*

In this approach we would have several static services (resource servers)
that orchestrate access and then each tenant is represented via a
dynamically registered client.

We would then have a static set of roles (permissions) which are assigned
between the user and client when they are granted access.

The total universe of roles is then fixed. The proliferation here is
between users and clients or resource-servers and clients.

## Second approach *Dynamic Role Generation*

In this approach we're considering dynamically generating roles
(permissions) for each tenant in the system. We're thinking of mirroring
AWS's URN style so that the permissions look something ssl_certificate_key

They follow the general structure `urn:service:tenant:permission`

E.g.

- urn:service-1:tenant-id-1:read
- urn:service-1:tenant-id-2:read
- urn:service-1:tenant-id-1:write
- urn:service-1:tenant-id-1:admin
- urn:service-2:tenant-id-1:read

This is very simple and powerful but we have the potential for the JWT to
proliferate in size as we connect a user or service to more and more
tenants.

I feel like the first approach is more standard but requires us to add more
complexity into the system since we have to deal with registering clients
and guiding the user through the auth delegation flow each time they want
to grant a server access to a client that they own.
The second approach is dead simple technically but less standards
compliant.

What do people tend to do in the real world to address this issue? Our
system has an unlimited number of tenants but realistically each user is
going to be associated with a few dozen at most. Third party applications
(which are all dynamic clients) will potentially be associated with
hundreds or thousands of other clients.