Multi-tenancy support for OAuth2

[jzheaux]

Summary

Today, it isn't clear how to best configure Spring Security to support a multi-tenant OAuth2 client.

Here is an example of one approach out in the wild:

https://github.com/thomasdarimont/spring-boot-2-keycloak-oauth-example/blob/feature/mulit-tenancy/src/main/java/demo/SpringBoot2App.java#L127

Though whether JwtDecoder is the ideal place and how tenants might possibly be treated in a more first-class way is yet to be seen. Opening this issue to get the conversation started.

[bertramn]

We indeed had the requirement to run a single resource server that can validate JWTs issued by multiple issuers. We had to implement our own given the Spring one does not support this and Keycloak adapters only support Keycloak specific issuers.

We had 2 main use cases for multi tenancy:

1. validate all inbound JWT with an Issuer whitelist

This use case requires the IssuerResolver to lookup (and cache) issuer metadata JWKS certs.

2. validate inbound JWT based on a pre-configured list of issuers

This use case requires a pre-configured IssuerResolver which is configured with the issuer (iss) name it supports and then either the metadata url or the public cert, where the later does not really work well if your issuer performs key rotation.

Another interesting aspect we ran into was that if we just want to run a API based resource server (ie. Spring Boot micro service) there will be a lot of unnecessary moving parts in the Spring Security configuration. We ended up implementing 3 components (AccessDeniedHandler, AuthenticationFailureHandler and AuthenticationEntryPoint), everything else is surplus and massively overcomplicates things.

[jgrandja]

Related #5385

[metacubed]

In a multi-tenant configuration, each tenant would likely come with its own set of allowed issuers. A tenant-specific request would trust only a subset of the issuers configured for the resource server.

We would need to introduce a selection mechanism to pick the allowed issuer(s) for a request. This IssuerListSelector could have custom implementations that are specific to the resource server.

For example, the keycloak-auth project uses the request.getServerName() to decide which decoder implementation to use. Other request attributes could also be used, such as the request sub-domain, a header, etc.