Multiple keys support in the jwks_uri url

[janz93]

First of all thank you 😃 for all the work that has been put into this project.
It helped me a lot to go get my app running without me needing to understand the specs in detail. 👍 🙏

Background

In the process of switching the access token to a JWT token, I used the doorkeeper-jwt gem as described in the doorkeeper guide and followed their instructions

I generated a new keypair and passed the information onto the secret_key method of doorkeeper-jwt.

Problem

I expected that the new keypair information to be displayed in the jwks_uri from the .well-known/openid-configuration

I discovered that only the one key defined in the doorkeeper-openid_connect configuration will be displayed in the jwks_uri URL

Question

1. Would it be possible to have a configuration where multiple keys are support?
   Multiple OAuth providers (AWS Cognito or 0Auth) use this principle.
   As this allows for a lot of flexibility in for example deprecating keypairs slowly

2. Additionally building on top of the assumption to have multiple key support. How could you get access to the keypair defined in the doorkeeper-jwt configuration? (Maybe this should be placed as a separate issue and maybe here is also not the right place but either the doorkeeper-jwt or doorkeeper if that is the case please let me in the comments)

ps. I hope this issue is as expect other also let me know and I'll adjust it accordantly

[toupeira]

@janz93 thanks for raising this issue!

1. Yes this should be possible in principle, as the jwks_uri responds with a keys: [] array.
2. Not sure, I'm not familiar with the doorkeeper-jwt gem or how JWTs are used in OAuth outside of an OIDC context. It sounds like it would make sense to have doorkeeper-jwt as a dependency so the configuration could be shared. Note that it's currently not needed if you just want to use doorkeeper-openid_connect, we do our own JWT setup in this gem.

[janz93]

@toupeira thank you for your response. Regarding the second point. I think since both gems are doing their own JWT setup a solution can not be found here in this issue. For the first point if possible I would like to take on this enhancement and create a PR with a possible solution for it.

[toupeira]

For the first point if possible I would like to take on this enhancement and create a PR with a possible solution for it.

@janz93 Sure that would be awesome! The only thing you have to watch out for is to still support a non-array value in existing configurations.

Regarding the second point. I think since both gems are doing their own JWT setup a solution can not be found here in this issue.

Yeah I guess there would be ways to do it, but not very cleanly 😉

[jeffsawatzky]

@janz93 We got around this by using the same key pair for doorkeeper-jwt as we did for doorkeeper-open_id_connect. If you are including a kid in your jwt access token, then make sure it is generated the same way that doorkeeper-open_id_connect generates it's kid in the jwks_uri

With that said, we would like to be able to rotate the keys that are used to sign the jwt access token / id token and be able to have the jwks_uri include the old public key as well as the newer one.

[dzleidig]

If you are including a kid in your jwt access token, then make sure it is generated the same way that doorkeeper-open_id_connect generates it's kid in the jwks_uri.

For those curious, the following worked for me:

   token_headers do |opts|
      key = OpenSSL::PKey.read File.read('<private_key>.pem')
      { kid: JSON::JWK.new(key)[:kid] }
    end