Missing keyValue for Public Key Configuration in OAuth2ResourceServerJwtConfiguration

[Thinkenterprise]

would it be possible to have the property keyValue via @ConfigurationProperties (prefix = "spring.security.oauth2.resourceserver") and a suitable decoder in OAuth2ResourceServerJwtConfiguration. For small quick tests it is easier to put the public key in the property file, as in 1.5.x.

[mbhave]

I think Spring Security currently only supports obtaining the public key used for verification from the JWK Set URL.

/cc @jzheaux

[jzheaux]

5.2 adds support for local public-key configuration, so it is certainly something that we can take a look at.

[Thinkenterprise]

The classes for the Spring Boot OAuth2 Autoconfiguration OAuth2ResourceServerPropertiesfor configuration and OAuth2ResourceServerJwtConfiguration for the token decoder generation come from Spring Boot Autoconfiguration Packages org.springframework.boot.autoconfigure.security.oauth2.resource.servlet. So I can not fully understand why this is a Spring Security issue. Or am I wrong?

My suggestion would be to extend both classes so that public keys can be configured using a property in * .yaml * .properties.

Like this:

security:
    oauth2:
      resourceserver:
        jwt:
          keyValue: |
            -----BEGIN PUBLIC KEY-----
            MIGfMA0GCS ...
            -----END PUBLIC KEY-----   

[jzheaux]

@Thinkenterprise it's a matter of supplying the conversion strategy to convert the encoded key into an instance of RSAPublicKey, for example. Something like this lives better in Spring Security.

But, yes, there would be some boot code that does the appropriate auto-configuration based on this value.

[wilkinsona]

I'm not in favour of making this change. I think it would be quite YAML-specific as I don't think it would work well in a properties file, as an environment variable, as a system properties, etc. Also, we don't allow keys to be configured directly for any other similar configuration properties and consistency is important.

[Thinkenterprise]

@wilkinsona If this is the basic approach of Spring Boot 2.0 to security, then I have to accept that. I think that is the responsibility of the developer. It is also a breaking change since this property was provided in version 1.5.x. For test cases, it would be a nice feature and also works with propety files. Especially as it uses it in a sample by referencing Spring Boot 2.0 from, I think @jzheaux ?

[rwinch]

I'm not in favour of making this change. I think it would be quite YAML-specific as I don't think it would work well in a properties file, as an environment variable, as a system properties, etc. Also, we don't allow keys to be configured directly for any other similar configuration properties and consistency is important.

Perhaps it makes more sense to support using a separate file and pointing at that file in the properties/yml file?

[jzheaux]

@Thinkenterprise The sample you are referencing is from a legacy OAuth 2.0 plugin--it's meant to illustrate how that plugin works. Please don't infer intended future capabilities for mainline Spring Security from it.

[wilkinsona]

Perhaps it makes more sense to support using a separate file and pointing at that file in the properties/yml file?

Yeah, that's what I think we should do.