How to override the behavior of OktaOAuth2PropertiesMappingEnvironmentPostProcessor in a @SpringBootTest
danallen88 opened this issue · 3 comments
I'm submitting a
- bug report
- feature request
Background info
I'm using this library to manage discovery of .well-known/openid-configuration, and validating JWT tokens before they are injected into my controller in a Spring Boot application. In my integration tests annotated with @SpringBootTest or @restclienttest, it appears the framework attempts to discover this endpoint on the internet and I can't find any docs on how to mock that out or ignore it. It ends up either making a dependency of our integration tests that we can actually reach out to our Auth0 tenant on the public internet, or if we use fake issuer/audience URLs each test takes 45 seconds before timing out and moving on. The error I'm seeing is:
Failed to process '.well-known/openid-configuration' metadata. Using defaults for Okta.
I can get around this by using URLs that will return this metadata, but that means that my integration tests - which before this could run without connecting to external services - now have a dependency on being able to reach these live services. I believe the right thing to do is to mock out this interaction, but I don't see how that's possible with this library.
Thank you for your help!
SDK Version
spring-boot-starter-parent 3.1.5
okta-spring-boot-starter 3.0.5
@danallen88 Thanks for posting!
The discovery of OIDC metadata from .well-known/openid-configuration is done automatically by Spring OIDC client during the registration process and this behavior is embedded inside the Spring Security framework and Okta does not define it. There is no known documented way in Spring framework to bypass this.
For testing purposes, if you have concerns about public internet calls, you could mock the metadata, serve a static metadata by using a framework such as Wiremock. In fact, this SDK has such tests inside oauth2/src/test/ that you can use for reference.
Let me know if that helps!
Thank you @arvindkrishnakumar-okta for confirming that there is no known documented way in Spring to bypass this, and thank you for pointing me to the tests that shows how Wiremock is used. Is this an example of such a test? https://github.com/okta/okta-spring-boot/blob/master/oauth2/src/test/groovy/com/okta/spring/boot/oauth/env/OktaOAuth2PropertiesMappingEnvironmentPostProcessorTest.groovy
Sure, please take a look at tests in oauth2/src/test/groovy/com/okta/spring/boot/oauth/.