Current Behaviour

In application.yml, when using the issuer-uri parameter on spring.security.oauth2.client.provider configuration, the whole application becomes dependent on that issuer-uri to point to an auth server that is up and running. In environments like stage and production, that should not be an issue.

But in SpringBootTests this can break loading the context, especially when executed in a CI environment where the default auth server may not be reachable.

Offending configuration

spring:
  security:
    oauth2:
      client:
        provider:
          keycloak:
            issuer-uri: ${oauth2.server.url}/realms/my-realm

Expected Behaviour

Setting issuer-uri should not break the whole application when the Issuer is not reachable via network. Alternatively I should be able to disable this usage of issuer-uri in test.

Possible Solution / Workaround

This piece of code is the culprit:

https://github.com/spring-projects/spring-boot/blob/b1f8024e8ad26271502302c219c59c4a684ff954/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/security/oauth2/client/OAuth2ClientPropertiesRegistrationAdapter.java#L82-L85

I think it may be easiest to check for issuer != null && !issuer.trim().isEmpty() so that I can at least reset the issuer-uri to be empty in an application-test.yml.

Comment From: wilkinsona

Rather than configuring the issuer-uri and then undoing that configuration, have you considered configuring it in a profile that isn't always active? That would allow you to run some of your tests without it.

Comment From: mrohlof-protofy

Yes, that is currently my workaround. It runs in a configuration that is only active when profile test is not present, much like in https://stackoverflow.com/q/72280016/4134934. But like OP of that question, I find it not very intuitive.

Although now that you also proposed it, that would probably be the Spring way of handling this situation.

Comment From: wilkinsona

We'd like to make it easier to unset a property. https://github.com/spring-projects/spring-boot/issues/24133 is tracking that improvement. Looking for that issue reminded me that we've seen this request before and declined it: https://github.com/spring-projects/spring-boot/issues/28139. The reasons for declining it still apply today so I'm going to close this as a duplicate.