Feature idea: Encrypted Request Object

[veijotom]

Hi,

I am working on an authentication service that utilizes OIDC and have found openid-client very useful in simplifying the server-side implementation. There is one feature, however, that I would like to see added: Encrypted Request Object.

This option is specified in the OpenID Connect Core document section 6.3.1
https://openid.net/specs/openid-connect-core-1_0.html#EncryptedRequestObject

Here is a short snippet of how our implementation roughly looks:

const authorizeUrl = await client.buildAuthorizationUrlWithJAR(config, params, signingKey);
if (
    config.serverMetadata().request_object_encryption_enc_values_supported?.length > 0 &&
    config.serverMetadata().request_object_encryption_alg_values_supported?.length > 0
) {
    const jwks = await getJwks(config.serverMetadata().jwks_uri);
    const signedRequest = authorizeUrl.searchParams.get('request');
    const encryptedRequest = await encrypt(signedRequest, jwks);
    authorizeUrl.searchParams.set('request', encryptedRequest);
}

The main issue is obtaining the JWKS (and maybe caching it). Since openid-client internally handles getting and caching the JWKS from the Authorization Server I would like to see this feature implemented to prevent having to maintain a "separate" JWKS cache for this purpose. Maybe this could be implemented as a discovery request option enableRequestObjectEncryption similar as enableNonRepudiationChecks, or as an explicit parameter in the buildAuthorizationUrlWithJAR method.

Perhaps an alternate feature would be a method that returns a fresh JWKS cache. I found the getJwksCache method, but I think it returns undefined if the cache hasn't been populated yet (which it probably isn't when first calling buildAuthorizationUrlWithJAR).

Any thoughts or suggestions?

[panva]

Any thoughts or suggestions?

I'm not convinced this is widely used/needed enough which is why I didn't include it in the 6.x redesign.

My thought on this was, and so my suggestion is, that users who need it would manage the encryption of the request object themselves.

jwks are not loaded for majority of v6.x use so you're good to load them with fetch yourself and encrypt with jose.CompactEncrypt

[veijotom]

Yeah, I see that it is probably not a widely used feature of OIDC. I should've mentioned that we operate in a context that mandates verifying the ID Token signature so the library will load the JWKS. Anyway, it's not a major issue, we will continue with manual encryption and JWKS handling.