feat: [#631] JWT Encryption support for client authentication and ID Token generation

[vivshankar]

See #631

Related Issue or Design Document

See #631

Checklist

• [x] I have read the contributing guidelines and signed the CLA.
• [x] I have referenced an issue containing the design document if my change introduces a new feature.
• [x] I have read the security policy.
• [x] I confirm that this pull request does not address a security vulnerability. If this pull request addresses a security vulnerability, I confirm that I got approval (please contact [email protected]) from the maintainers to push the changes.
• [x] I have added tests that prove my fix is effective or that my feature works.
• [x] I have added the necessary documentation within the code base (if appropriate).

Further comments

[vivshankar]

@aeneasr Before I go too far down this rabbit hole, I wanted your opinion on replacing the current mechanism for validating JWTs that effectively relies on a KeyFunc returning a key, typically from jwks/jwks_uri config. In the implementation I am introducing here, starting with client authentication, I am expanding support to do the following -

• Preserve current behavior to support jwks/jwks_uri based validation
• Decryption for JWEs
• Custom validation strategy for JWTs that might, for example, leverage a trust store or a key management service that offers crypto APIs etc.
• Introducing some security controls around "allowed key IDs" and "allowed algs". The former is important IMO as seen in a recent hack. The latter is useful to enforce requirements for PS256 and ES256 type algorithms required by FAPI and other high assurance flows.

I have a few cases where the approach I am introducing here applies or will apply -

1. Request object
2. DCR with SSA validation and DCR client_metadata as application/jose (AU-CDR, for example, uses this)
3. Token exchange for custom JWT type as a subject or actor token
4. JWT bearer grant flow (would be an enhancement on top of what is available today)

In all cases, I am trying to preserve the current behavior (unit tests confirm it) while adding this extra option to validate the JWT but it may effectively negate the need for some functions that are in use today. It also introduces decryption as part of the same set of changes.

Note here that I am specifically referring to incoming JWTs. The PR also carries a mechanism to encrypt outgoing JWTs for id_tokens, JARM, userinfo as JWT etc. I know some of these aren't yet in place but this sets the foundation to add those capabilities.

I am, by no means, done with this PR though it is ready for review.