Add a PrivateKeyManager to make the processes involving private keys customizable

[DaanBiesterbos]

Hi there!

It would be great to separate the logic of using and loading private keys from the bundle and core library. The Jose web token bundle provides awesome features that align with the RFC's related to oauth. The private key is currently tightly coupled to a keypair and the services that use it.

Our OAuth server issues JWT's, we don't use opaque tokens. Currently, the system is far from ideal. And since this regards security I'd love to work on it. But that will be very difficult, since it seems like integrating more advanced flows and strategies requires me to override way more then I want. Until a point that it might very well be better to start over. And I won't get clearance to do that. I love my work - but I am not doing all of that at home either. Lol.

I feel like keysets, public key discovery (JKU's), seamless key rotation are needed in todays day and age. It would be very easy to integrate the Jose webtoken bundle if the bundle was open to extension in this area. So I feel like it would be a good idea to separate key management from the oauth server library and bundle.

Use cases:

• The AS might issue a JWT that includes a protected kid header. The RS loads public keys using a JKU. (Jose web token bundle already provides this functionality, I'd only need a way to "wire" the JWK or JWKSet
• Discovered public keys are cached, so for seamless rotation I'd like to be able to generate the private key ahead of time. This is not logic this bundle needs to be concerned with. However, if I am able to load private keys any way I want I want just use a cloud secret to load the "current" private key used for signing. Just being able to customize the logic to load a private key would be needed.
• It would be nice to make the creation access tokens more flexible for situations where we want to use JWT's. Ideally I'd like to use a RFC927 URN (like urn:ietf:params:oauth:jwk-thumbprint:sha-256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs) as a deterministic identifier. Allowing any service to recreate the unique ID from either the public or private key.

Additional advantages:

• When public keys are discovered and keys are paired to issued tokens it becomes possible to expand on that. OAuth 2.1 is a lot more focused on resource restriction. Although it's a recommendation, it's a good idea to provide to request access to a specific resource. The issued JWT will contain that resource as the audience, which the RS uses to check if the JWT was issued for that service, or reject it otherwise. This would be highly impractical without the Token Exchange grant. Which is basically just a way to exchange use a previously issued JWT as a credential to request access to another resource. I'd like a more solid and flexible foundation to build on.
• Depending on the circumstances it might be preferred (or even required) to have multiple (private) key sets. For example, per grant. Or maybe even per RS. You can make the resource parameter mandatory. When public keys are discoverable, there is nothing stopping us from using different private keys for different domains to further harden the security. In todays day and age, I think this is a must.

It seems to me that the current approach encourages companies to build something that works as soon as possible and not look at it. Ultimately leading to insufficient precautions (because who wants to often rotate keys if issued tokens can no longer be verified, in-house solutions feel off. The examples I gave earlier require a sufficient amount of control to implement correctly. I am in the situation right tbh. If I can offer a clean path forward I'm sure I'd get approval to work on it. But rebuilding the entire oauth implementation from scratch, that's not going to happen. We'll "one day" look at alternatives. But until then, the path forward involves super tokens (no token exchange, resource restriction, etc), a single private key, less frequest rotations etc. Which makes me feel like the bundle needs some innovating improvements to keep up.

I might consider contributing. But it would involve some pretty impactful changes. So it's not something I'd just start working. I am very busy with other things at the moment.