Signed and encrypted messages in your tenant

A client's encryption key

A client registers its public encryption key in its key set, under Client public keys in Access Token Management, inline or from its jwks_uri. An encryption key must say "use": "enc": an RSA key of at least 2048 bits for RSA-OAEP-256 or RSA-OAEP, or an EC key on P-256, P-384 or P-521 for ECDH-ES, ECDH-ES+A128KW or ECDH-ES+A256KW. A key marked for encryption never checks a signature, and a signing key is never used to encrypt. The private half stays with the client. The lab toolkit makes such a key with btl-lab jwk --use enc.

Encrypted responses

In the client's settings, choose an encryption algorithm (alg) and, optionally, a content encryption (enc: A128CBC-HS256 by default, A256CBC-HS512, A128GCM or A256GCM) for any of:

• ID tokens (id_token_encrypted_response_alg): from the token endpoint and from the authorization endpoint.
• UserInfo (userinfo_encrypted_response_alg): the response is application/jwt, a JWE whose payload is the signed UserInfo JWT when signing is on, or the JSON claims when it is off.
• Authorization responses (authorization_encrypted_response_alg): with a .jwt response mode (JARM), the signed response JWT is encrypted.

The encrypted message's header names alg, enc, the client key's kid, and cty: "JWT" when it holds a signed JWT. Saving an encryption choice needs the client's key set first. A key set pasted inline must already hold a key marked for encryption that suits each chosen algorithm (RSA for RSA-OAEP, EC for ECDH-ES); a key set at a jwks_uri is checked each time a response is encrypted. Changing these settings grants nothing new, so it revokes nothing.

Signed UserInfo

With Sign UserInfo responses with set (ES256, RS256, PS256 or EdDSA, from the tenant's active keys), UserInfo answers application/jwt: the claims as a JWT your tenant signs, with iss (your issuer) and aud (the client ID) added (OpenID Connect Core section 5.3.2).

Encrypted request objects

In Key Management, generate an encryption key (RSA-OAEP-256 or ECDH-ES). Its public half appears in your tenant's key set with "use": "enc". A client can then encrypt its signed request object to that key (RFC 9101 section 6.1) and send the five-part result as request, or inside a pushed request. The inner request object must still be signed by the client and passes every usual check. A retiring encryption key still opens requests encrypted to it; a disabled one leaves the key set.

The same key opens an id_token_hint that a client received encrypted and encrypted again to your tenant before sending it, at the authorization endpoint, at sign-out and in CIBA requests (OpenID Connect Core section 3.1.2.1). The ID token inside is checked as an unencrypted hint is.

Refusals and discovery

If a client's key set no longer has a suitable encryption key, the response fails with server_error and a reference ID; Audit records encryption_key_unavailable. A request object that cannot be opened is refused with request_object_decryption_failed, or request_object_encrypted while your tenant has no encryption key. Discovery lists id_token_encryption_alg_values_supported, userinfo_signing_alg_values_supported, userinfo_encryption_alg_values_supported, the authorization_encryption values while a .jwt mode is allowed, and request_object_encryption_alg_values_supported while you have an encryption key, each with its enc values. A tenant can have 10 encryption keys in use.