Support different OIDC issuer hostnames for frontend/backend endpoints

[heruan]

Expected Behavior

When the OIDC provider uses different hostnames from frontend and backend endpoints, fetching metadata from the configure issuer hostname does not fail.

Current Behavior

If the frontend and backend hostnames differs when fetching metadata, a validation exception is thrown.

Context

Consider a Spring application running inside a Kubernetes cluster, and it needs to authenticate against an OIDC server inside the same cluster (say Keycloak). Hostnames used inside the cluster are different from the public ones, and this is supported by Keycloak (frontend and backend hostnames can be different).

The Spring app has this configuration:

spring.security.oauth2.client.provider.keycloak.issuer-uri: http://internal:8180/realms/foo

When fetching metadata from there, Keycloak returns:

{
    "issuer": "https://external/realms/foo",
    "authorization_endpoint": "https://external/realms/foo/protocol/openid-connect/auth",
    "token_endpoint": "http://internal:8180/realms/foo/protocol/openid-connect/token",
    "introspection_endpoint": "http://internal:8180/realms/foo/protocol/openid-connect/token/introspect",
    "userinfo_endpoint": "http://internal:8180/realms/foo/protocol/openid-connect/userinfo",
    "end_session_endpoint": "https://external/realms/foo/protocol/openid-connect/logout",
    "...": "..."
}

As expected, the frontend endpoints use https://external and backend endpoints use http://internal:8180.

The problem is that when fetching metadata, Spring fails here:

spring-security/oauth2/oauth2-client/src/main/java/org/springframework/security/oauth2/client/registration/ClientRegistrations.java

Lines 246 to 248 in 9c6b5f9

	Assert.state(issuer.equals(metadataIssuer),
	() -> "The Issuer \"" + metadataIssuer + "\" provided in the configuration metadata did "
	+ "not match the requested issuer \"" + issuer + "\"");

Fetching metadata from the issuer is necessary since some endpoints are read only from metadata, e.g the end_session_endpoint:

spring-security/oauth2/oauth2-client/src/main/java/org/springframework/security/oauth2/client/oidc/web/logout/OidcClientInitiatedLogoutSuccessHandler.java

Lines 79 to 80 in 9c6b5f9

	ProviderDetails providerDetails = clientRegistration.getProviderDetails();
	Object endSessionEndpoint = providerDetails.getConfigurationMetadata().get("end_session_endpoint");

But also other back-channel endpoints without configuration properties in application.yaml.

Since I know both internal and external hostnames, how can I make Spring Security fetch metadata from the internal issuer hostname and accept the external hostname in metadata?

Note: a similar scenario has been solved for JWT decoders in #10309

[jzheaux]

Hi, @heruan! Thanks for the report.

I think the sticky part is the following from the Authorization Server Metadata spec:

The "issuer" value returned MUST be identical to the authorization
server's issuer identifier value into which the well-known URI string
was inserted to create the URL used to retrieve the metadata. If
these values are not identical, the data contained in the response
MUST NOT be used.

Because of that, Spring Security requires they match by default, which generates a question: Are you able to query using the external URI?

If not, the Boot property might not be the best fit for your arrangement. I don't think we want to add something that switches off spec-related validation, but I think it does make sense to add ClientRegistrations#fromMetadata(Map). This would allow you to make your internal request (say with RestTemplate), perform any validation, and then let ClientRegistrations do the rest:

@Bean 
ClientRegistrationRepository clients(RestTemplate rest) {
    Map<String, Object> metadata = rest.getForObject(...);
    // ... validate on your own
    return new InMemoryClientRegistrationRepository(ClientRegistrations.fromMetadata(metadata));
}

Would either of these approaches work for you?

[heruan]

Hey @jzheaux thanks for the feedback! I'm not able to query using the external URI, so I'd need another approach. How would the fromMetadata(Map) work with other properties from the Boot configuration, e.g. client-id, client-secret or scope? Take for example this YAML:

spring:
  security:
    oauth2:
      client:
        provider:
          keycloak:
            issuer-uri: http://internal:8180/realms/foo
        registration:
          keycloak:
            client-id: my-client
            client-secret: my-secret
            scope:
            - openid

With the current implementation the OAuth2ClientPropertiesMapper merges the metadata fetched from the issuer-uri with the properties in the registration subtree. Would it be possible to hook up your suggested approach in the mapper, so that if a issuer-uri is not provided for a registration there's still a chance to get a builder with provided metadata?

I suppose that would be somewhere around here: OAuth2ClientPropertiesMapper.java#L71-L74

I need this to be configuration based since applications run in a cluster and configuration is provisioned with config-maps so if I add code it should be generic enough to work with different configurations.

[heruan]

I've tried different approaches to this without much luck. Only configuring with Boot properties successfully configures everything needed for OIDC to work properly, e.g. scopes, tokens, back-channel logout, etc.

That part of the spec you mentioned looks to be known to be problematic, as it doesn't take into account valid scenarios like the one I described where the app communicates with the issuer with a backend URL. Quarkus provides a way to skip issuer validation in that sense and also Vault is dealing with this.

Would it be acceptable to have a Boot property to specify the issuer value expected from metadata to perform validation?

spring:
  security:
    oauth2:
      client:
        provider:
          keycloak:
            issuer-uri: http://internal:8180/realms/foo
            metadata-issuer: https://external/realms/foo

[heruan]

@jzheaux any further comments on this? It's also being discussed in keycloak/keycloak#24252 (comment) first and then keycloak/keycloak#29783 for a Keycloak-specific approach, but I read mentions of the same topic being an issue in Vault and other OIDC based projects.

[chvndb]

I'm having the same issue, any solution or workaround for now?

[lyca]

I'm having the same issue, any solution or workaround for now?

The easiest "workaround" is to not set the issuer-uri at all and instead only configure the jwk-set-uri.

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          jwk-set-uri: https://idp.example.org/.well-known/jwks.json

Without the issuer-uri configured, the demanded check from 4.3. OpenID Provider Configuration Validation would not be made.

The issuer value returned MUST be identical to the Issuer URL that was directly used to retrieve the configuration information.

Also the issuer validation with the JwtIssuerValidator will not be active. If the validation is needed, one could bring it back by configuring the JwtDecoder as a bean.

[vbbonev]

I have the same problem (Spring boot + Keycloak behind nginx reverse proxy -> all in docker containers). The workaround that I use is to set alias on the nginx container (alias=external.com) and from spring --> keycloak.issuer-uri: https://external.com.....