Add JWE (Encrypted) support for UserInfo endpoint based on RP configuration

[nandhu-kumar]

Related Feature Issue

fixes #2372
New feature proposal extending existing JWS implementation

Problem Summary

Currently, Thunder supports UserInfo responses in JSON and JWS (signed) formats. However, there is no support for encrypted UserInfo responses (JWE), which are required in scenarios where sensitive user claims must be protected from intermediaries or unintended exposure.

Adding JWE support will enhance security by ensuring confidentiality of user claims in transit.

High-Level Approach

The proposal is to extend the existing UserInfo response handling to support a new response type: JWE.

• Introduce JWE as a valid UserInfoResponseType
• Extend client (application) configuration to accept encryption details
• Use RP-provided public key (or JWKS) to encrypt UserInfo response
• Reuse existing response-building flow:
  • Build claims → Sign (optional) → Encrypt (new step)

Architecture Overview

1. Application Layer Changes

Extend UserInfoConfig to include encryption details:

type UserInfoEncryptionConfig struct {
    Alg       string
    Enc       string
    PublicKey string // or JWKS
}

type UserInfoConfig struct {
    ResponseType   UserInfoResponseType
    UserAttributes []string
    Encryption     *UserInfoEncryptionConfig
}

2. Client Management API

Enhance application onboarding payload:

"user_info": {
  "response_type": "JWE",
  "user_attributes": ["email", "name"],
  "encryption": {
    "alg": "RSA-OAEP-256",
    "enc": "A256GCM",
    "public_key": "-----BEGIN PUBLIC KEY-----..."
  }
}

3. UserInfo Service

Extend existing flow:

• JSON → return JSON
• JWS → sign response
• JWE → encrypt response (new)

Add new method:

generateJWEUserInfo(...)

Responsibilities:

• Encrypt claims using RP public key
• Produce compact JWE
• Return as application/jwt

4. Handler Layer

Reuse existing handler logic:

• Detect response type
• If JWE → return encrypted payload

Set header:

Content-Type: application/jwt

Security Considerations

• Ensure only valid public keys/JWKS are accepted during onboarding
• Prevent weak or unsupported algorithms

Recommended initial support:

• alg: RSA-OAEP-256
• enc: A256GCM

Consider enforcing:

• Key validation during client registration
• Avoid exposing sensitive claims in logs

Impacted Areas

• Application model (UserInfoConfig)
• Client management API
• UserInfo service (userinfo/service.go)
• UserInfo handler
• JOSE/JWT utilities (encryption support)
• Integration and unit tests

Alternatives Considered

1. Only support JWS

• Already implemented
• Does not provide confidentiality
• ❌ Not sufficient for sensitive data use cases

2. Encrypt raw JSON without JWT

• Simpler implementation
• Not aligned with OIDC expectations
• ❌ Rejected

Questions for Community Input

• Should we support JWKS URI-based key retrieval or only static public keys initially?
• Do we enforce nested JWT (JWS → JWE) or allow direct encryption of JSON?
• Should encryption config be:
  • Part of user_info config only
  • Or shared with ID token (future extensibility)?
• How should we handle key rotation?
• Should we validate encryption config strictly during application creation?

[thiva-k]

Hi @nandhu-kumar,

Should we support JWKS URI-based key retrieval or only static public keys initially?

I believe using the existing JWKS/JWKS_URI for the JWE would be enough. We can reuse the existing OAuth-level cert we have in application config for this. Having a separate public PEM for this purpose would further complicate the config and key management and I see no additional benefit too. Further, DCR and other specs also propose JWKS/JWKS_URI only right?

Do we enforce nested JWT (JWS → JWE) or allow direct encryption of JSON?

Shall we have another response type for nested JWE.

Let's have a separate config for user info related signing/encryption, since we may need to enforce them separately for ID token. DCR also follows this approach

Additionally let's try to align the new application properties we introduce with the DCR spec wherever possible. We should also update the DCR side of this along with our application API implementation.
e.g. Based whether encryption alg or signing alg is sent, set the repsonse_type be JWS or JWE or nested etc. internally. Also seems we are still using the app-level cert to store the jwks/jwks uri in DCR path even after introducing OAuth level app certificate.

And any reason for not introducing signing algorithm field? Better to have it for consistency for now and we can decide the algorithm negotiation when the support is there later.

We should also update the discovery endpoint to expose the supported algorithms from Thunder for signing, encryption as per the spec.

[anushasunkada]

@nandhu-kumar - Encryption protects secrecy, but it does not by itself prove who created the data — signatures are required for non-repudiation, so when JWE is enabled we must sign before encryption.

Reuse existing response-building flow:
Build claims → Sign (optional) → Encrypt (new step)

As @thiva-k mentioned, we should have nested JWE as another response type.

Can we have deployment level restriction on which options are allowed as userinfo/ID-token type during app registration? As we may need to only allow JWS and Nested JWT.

Also @thiva-k, Currently for what purpose is the application level certificate used?

Current ApplicationCertificate structure only takes one certificate or one JWK. We should improve this to take JWKS or list of certificates.

@nandhu-kumar
To be fully compatible with DCR, we should explicitly as the client to provide encryption algorithm for both userinfo and id-token separately so that during id-token or userinfo building we search and pick the matching key from given JWKS or JWKS_URI or list of certificates.

[thiva-k]

Hi @anushasunkada,

Currently for what purpose is the application level certificate used?

Currently is it not being used in runtime for anything. This was introduced for allowing app-specific signing/encryption of assertions if needed, which has not been implemented yet. Private key jwt, etc. uses oauth-level certificate. The DCR side is erroneously storing the cert in the app-level one instead of the oauth-level one currently.

Current ApplicationCertificate structure only takes one certificate or one JWK. We should improve this to take JWKS or list of certificates.

I believe we support JWKS as of now. In private key JWT we are matching by kid from the set. Correct me if I am wrong

[anushasunkada]

I went by this docString in the struct

`json:"value,omitempty" yaml:"value,omitempty" jsonschema:"Certificate value. The actual certificate content in the format specified by type. For PEM: base64-encoded certificate. For JWK: JSON Web Key."

But now I see that type is tied to CertificateType

const (
// CertificateTypeNone represents no certificate.
CertificateTypeNone CertificateType = "NONE"
// CertificateTypeJWKS represents a JSON Web Key Set (JWKS) certificate.
CertificateTypeJWKS CertificateType = "JWKS"
// CertificateTypeJWKSURI represents a JWKS URI certificate.
CertificateTypeJWKSURI CertificateType = "JWKS_URI"
)

Then it's possible to use the same structure.

what is the meaning of NONE here? is it assumed to be PEM if its set to NONE ?