Support IdTokens which are returned encrypted in the code exchange response

[sberyozkin]

Fixes #26317.

OIDC spec allows for IdTokens being inner-signed and encrypted as opposed to signed only which is a typical case.
At the moment Quarkus will treat the encrypted tokens as opaque tokens and forward them for the remote introspection to the providers with the token content expected to be returned in the introspection response.

However, the case in #26317 is different. The provider is set up with the client public key only which it uses to encrypt the token while the private key is not known to the provider and only the client/Quarkus endpoint can be aware of it.

This PR adds a quarkus.oidc.token.decryption-key-location property which for now is only used for decrypting the id tokens but might be used for decrypting the access tokens in the future too. RSA-OAEP/A256GCM pair of algorithms is used by default but it will become customizable once such a requirement arises.

If this key location is set and IDToken is considered to be encrypted then it will decrypt it.
The important thing is that it should not be saved in a decrypted form in a session cookie (which is what happens with a workaround in #26317) since it will conflict with the purpose of encrypting the ID token on the provider level - it is done only if IdToken is considered to contain sensitive claims

[sberyozkin]

Sorry for last force pushes, I only seem to notice doc typos when I open a main branch PR :-)

[sberyozkin]

I'll need to check PEM formatted keys

[pedroigor]

@sberyozkin LGTM. As discussed, perhaps we can fallback to the private key already configured for the client (e.g.: authentication) to decrypt tokens. I think that would make things easier for those relying on the same keys for signing and encrypting.

[sberyozkin]

Thanks @pedroigor, it is a good idea, and in fact it has helped me realize the current solution is not good enough, because it does not work in a multi-tenancy case :-), so this PR will need more work.

[sberyozkin]

@pedroigor Sorry, got confused on Friday, it works as is right now for the multi-tenancy case but indeed, will have a look at the fallback to the private_key_jwt authentication key idea

[sberyozkin]

Hey @pedroigor So, I've added an option to fallback to the client private key if the private_jwt_key authentication method is used, if the decryptionKeyLocation is not set, and updated the docs. That would definitely be simpler for the the private_jwt_key users. Thanks for the idea.
I'll merge once the build passes