When using OAuth2ResourceServer which uses OAuth2ResourceServerJwtConfiguration internally for auto configuration, following methods can be used to create the JwtDecoder out of the box.

  • Specify jwk set uri spring.security.oauth2.resourceserver.jwt.jwk-set-uri property
  • Specify public key location under spring.security.oauth2.resourceserver.jwt.public-key-location property
  • Specify issuer uri under spring.security.oauth2.resourceserver.jwt.issuer-uri property

It would be nice if you can provide the ability to load RSAPublicKey from a keystore. The use case will be when a user want to create a stateless REST API with JWT authentication where the user will be generating the JWT themself (say from a /login custom endpoint) instead of through an authorization server. In such a case, it's easier to maintain a single keystore with the keypair in it.

I agree that we can have the private key in a keystore separately and the public key in a file and specify spring.security.oauth2.resourceserver.jwt.public-key-location with the public key for the above use case. However, I think adding support for a keystore out of the box is good from developers' perspective. If you think this is a nice to have feature, I would like to send a PR with the required implementation.

Comment From: wilkinsona

@IMS94 Thanks for the suggestion. I'm a little concerned that providing two different ways to do the same thing will result in some confusion. For example, if both a public key location and a KeyStore have been configured, from where should the public key be loaded?

@jgrandja what's your take on this please?

Comment From: IMS94

@wilkinsona Agree with your point. If that's the case we have to give priority to one over the other (via org.springframework.boot.autoconfigure.security.oauth2.resource.KeyValueCondition). But I'm not sure if that will affect adversely on developer experience. I assume that removing the jwt.public-key-location is not an option due to backward compatibility.

If giving priority over another is not an option, we won't be able to support my suggestion. What do you think?

Comment From: wilkinsona

jwt.public-key-location could be removed after a period of deprecation, but I don't think we would want to do so. Requiring a key store would complicate things for those who only want to configure a public key.

I'm leaning towards closing this one at the moment as I think the confusion that it may create will outweigh the benefits. I'd still like to hear from @jgrandja before making a decision.

Comment From: mbhave

I think this is a pretty niche use case which can be achieved by providing a custom JwtDecoder bean.

Comment From: IMS94

@mbhave @wilkinsona Agree with you both. Seems like there's no need to support this at this moment.

Comment From: wilkinsona

Thanks, @mbhave. Let's close this one then. Thanks again for the suggestion, @IMS94.

Comment From: IMS94

No problem 👍