Allow to configure IssuerResolver

[malaquf]

Expected Behavior Allow to configure AuthorizationServerContextFilter or IssuerResolver.

Current Behavior AuthorizationServerContextFilter and IssuerResolver are private, not possible to configure or disable.

Context I understand that current IusserResolver behavior is intended and in accordance to OIDC specs, as replied in issue 1869. However, as we already had a custom implementation of multi tenancy prior to the new spring authorization server (even prior to OIDC errata), based on Spring Oauth2, and we also have scenarios where our api gateway can be resolved from multiple domains, we'd like to be able to have a clear migration path without breaking our clients, and for this, the approach recommended on issue 1869 is not ideal, as it relies on filter ordering (suggested SecurityContextPersistenceFilter filter is already no longer accessible, for example), and makes the solution not reliable.

Spring itself is highly customizable, but when it comes to to authorization server, it is extremely painful to deal with all those final protected classes in a reliable way, while keeping clients compatible and plan for migration paths. This could definetely be improved (another e.g.: org.springframework.security.oauth2.server.authorization.web.authentication.OAuth2EndpointUtils which can't be reused in case of customization of converters and requires copying the implementation somewhere else).

[jgrandja]

@malaquf

when it comes to to authorization server, it is extremely painful to deal with all those final protected classes in a reliable way

FYI, the Spring Security team favours composition vs. inheritance for class design, hence the final classes. If there is a specific hook you are looking for, please log a new issue with specific details and we'll look into it. General comments like that are usually not helpful.

as we already had a custom implementation of multi tenancy prior to the new spring authorization server

Can you provide more details on your custom implementation? I need to understand what the specific issue you are having for the migration.

[malaquf]

@jgrandja

FYI, the Spring Security team favours composition vs. inheritance for class design, hence the final classes. If there is a specific hook you are looking for, please log a new issue with specific details and we'll look into it. General comments like that are usually not helpful.

You're right. Thanks for pointing it out. I reported some here, for example: https://github.com/spring-projects/spring-authorization-server/issues/2109 and https://github.com/spring-projects/spring-authorization-server/issues/2110

Can you provide more details on your custom implementation? I need to understand what the specific issue you are having for the migration.

We previously implemented multi-tenancy using path-based tenant resolution (e.g. /tenantA/oauth2/token, /tenantB/oauth2/token). All tokens, however, were issued with a single issuer value, regardless of the tenant.

However, during migration to the new Spring Authorization Server with multitenancy support, we're encountering the following issues:

Fixed Issuer Limitation: In the new setup, once multipleIssuersSupported(true) is enabled to allow path-based multitenancy, we’re not allowed to explicitly set a fixed issuer via AuthorizationServerSettings. This breaks backward compatibility, since we must continue issuing tokens with our existing issuer to avoid breaking JWT validation for external clients (who expect a specific iss claim).

E.g.:

@Bean
public AuthorizationServerSettings authorizationServerSettings() {
    return AuthorizationServerSettings.builder()
        .multipleIssuersSupported(true) <-- required for multitenancy
        // .issuer(...) <-- contradicts with multipleIssuersSupported and is not allowed.
        .build();
}

Rollback Requirement: We’re performing a transparent migration. To reduce risk, we want the ability to rollback to the previous version without forcing users to re-authenticate. This requires consistency in the issuer value across both versions.

Multiple Domains: Our service is currently reachable via two domains:

• One for internal users
• One for external users

In the end, both domains route to the same application instances and report same issuer in our old AuthServer.

Because of these constraints, we need a way to use the same static issuer across all tenant paths and domains, even when multitenancy is enabled. But the current AuthorizationServerSettings API doesn’t support this combination nor allows for easy customisation without depending on hardcoding it in a filter which depends on startup order of other spring internal filters, which is not optimal and can easily break on future updates.

Therefore, my request is about providing a less intrusive way to override the issuer for compatibility purpose.

[jgrandja]

@malaquf

we need a way to use the same static issuer across all tenant paths and domains, even when multitenancy is enabled

You can override any of the default claims (or headers) using an OAuth2TokenCustomizer<JwtEncodingContext> @Bean. Please see the reference doc for further details.

This should allow you to override the iss claim to be the same for all tenants?

[malaquf]

@jgrandja In regards to access tokens, yes, but the oidc well known endpoints would still report wrong iss.

[jgrandja]

@malaquf

but the oidc well known endpoints would still report wrong iss

I'm not sure I understand. Can you provide more detail?

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[Hydrawisk793]

@jgrandja

Hi. I think that i can give you some examples for the reason that i also want to customize the IssuerResolver.

I want to write an OIDC server that handles multiple tenants. Each tenant has an unique base URL. For example, the base URL of tenant A is https://tenant-a.com/a/b/c and the base URL of tenant B is https://tenant-b.com/w/x/y/z.

In case of tenant A, the OIDC endpoints should be like following: well-known openid-configuration : https://tenant-a.com/a/b/c/.well-known/openid-configuration authorization : https://tenant-a.com/a/b/c/authorize token : https://tenant-a.com/a/b/c/token And the value of iss claim should be https://tenant-a.com/a/b/c.

In case of tenant B, the OIDC endpoints should be like following: well-known openid-configuration : https://tenant-b.com/w/x/y/z/.well-known/openid-configuration authorization : https://tenant-b.com/w/x/y/z/authorize token : https://tenant-b.com/w/x/y/z/token And the value of iss claim should be https://tenant-b.com/w/x/y/z.

Thanks.

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[spring-projects-issues]

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.