Identity responses for your application's eyes

A signed identity response lets your application check where the information came from and whether it has changed. Encryption adds another useful property: the response is readable by the recipient holding the matching private key. M7 Identity supports both, signing selected responses and then encrypting the signed result for your application.

That can matter when identity information passes through a surface your backend does not need to share it with. Consider an application receiving an authorization response through the user's browser. With encrypted JARM—the signed JWT form of an authorization response—the authorization code, state or eligible error fields travel inside an encrypted envelope. The browser carries that envelope to the application's server; the server opens it using its private decryption key.

The browser still has a role in the journey, but it does not need to read the contents of that envelope. HTTPS remains part of the connection, and the application's normal login checks still matter.

Choose which responses to encrypt

M7 offers encryption separately for ID tokens, JARM authorization responses and signed UserInfo. Each is opt-in, so you can select the response types your application needs. Once encryption is required for a selected response, M7 does not quietly fall back to a readable response if encryption cannot be completed.

These responses arrive by different paths. In an authorization-code flow, the ID token arrives from the token endpoint. UserInfo is fetched separately. The browser-carried example above describes JARM; it does not turn every identity response into a browser redirect.

Your application registers its public encryption key, either directly as a JSON Web Key Set or through an HTTPS JWKS URL. It keeps the matching private key protected on the receiving server. That recipient key has its own job, separate from client authentication and request signing.

The supported encryption profile is RSA-OAEP-256 with A256GCM. Signing remains configured separately. Encrypted JARM also needs a registered JWT response mode, and encrypted UserInfo needs the supported signed-UserInfo policy. The M7 response-encryption guide explains those choices.

Open it, then check it

Successful decryption is the beginning of processing. The application must still verify the inner signature and check the relevant issuer, audience, expiry and transaction or identity claims. Depending on the response, that includes matching saved state or nonce, or checking that UserInfo belongs to the expected subject.

Use a compatible receiver and follow the SDK receiving guide. Plan key rotation too: older private keys may still be needed to open responses from transactions already under way. A hosted public-key URL does not remove that responsibility.

This adds confidentiality to selected responses while keeping signature validation in place. It is a separate choice from signed JAR requests and the signing profiles discussed in our post-quantum signatures article. It does not enable encrypted inbound JAR requests.

For a server-side application that needs recipient confidentiality, it is a practical extra layer. Keep the private key on the server, retain the usual login checks, and treat the information as sensitive after opening it too. Encryption does not make captured responses safe to log or protect an application whose own key has been compromised.