When does an OpenID Connect UserInfo response arrive as `application/jwt` instead of `application/json`?

Most deployments never see anything but a JSON object come back from the UserInfo endpoint. The specification allows two more shapes, and knowing why they exist — and what they change — is the refinement that separates someone who has read the endpoint's definition from someone who has only called it. ## Three shapes of the same answer | shape | media type | integrity of the body | who can read it | |---|---|---|---| | plain claims | `application/json` | none in the body; the TLS channel carries it | anyone the channel terminates at | | signed claims | `application/jwt` | the provider's signature travels with the body | anyone who receives it | | encrypted claims | `application/jwt` | present only if it was also signed | only the holder of the decryption key | Two consequences fall straight out of the table. First, a plain JSON response has **no integrity of its own** — if it is copied out of the connection into a log, a queue or a cache, nothing downstream can tell whether it was altered. Second, a signed response keeps its integrity wherever it is carried, which is the reason to ask for one: not because the channel is untrusted, but because the body outlives the channel. ## The order matters when both are asked for - **Signed only.** The claims sit in a signed token. Anyone can read them; nobody can change them undetected. - **Encrypted only.** This is permitted. The claims are confidential to the intended reader, but the body carries no signature, so its integrity rests on the same channel a plain JSON body would have relied on. - **Both.** The response is **signed, then encrypted** — a nested token. The relying party decrypts the outer layer first and verifies the inner signature second. Getting that order backwards is the classic mistake, and the reason the order is fixed is easy to state: a signature applied to ciphertext proves only that someone encrypted some bytes. A signature applied to the claims and then hidden inside the encryption proves that the provider asserted **those claims**, and the assertion survives being decrypted. ## What a signed response carries beyond the claims A signed UserInfo response carries `iss` and `aud` as members alongside the claims about the end user: - `iss` is the provider's issuer identifier, compared by the relying party against the issuer it believes it is talking to. - `aud` is or includes the relying party's own client identifier, so a response produced for one client cannot be replayed into another. That is the same three-way habit this whole branch is built on — the body names its origin, the body names its audience, and the receiver checks both against what it knows rather than against what the body says about itself. ## Finding out what a provider will do The provider's configuration document advertises its capability: `userinfo_signing_alg_values_supported` lists the algorithms it can sign a UserInfo response with, and the absence of the member says the provider does not offer signed responses at all. The endpoint's own location is the `userinfo_endpoint` member of the same document. Whether a given client actually receives signed or encrypted responses is fixed by that client's registration, not chosen per request — which is why two clients at one provider can legitimately see different media types. ## What does not change This is the part candidates skip. Wrapping the claims changes the body's integrity and confidentiality; it changes nothing about **whose** claims they are. 1. The response still carries `sub`, and the relying party still compares it with the ID token's `sub` before using a single member. 2. A verified signature proves origin and integrity, not that the presented access token belonged to the person who signed in. 3. The endpoint is still a protected resource reached over TLS with a bearer credential; the response format is not a substitute for the channel. ## When it is worth asking for Ask for a signed response when the claims will be stored, forwarded or replayed somewhere the original connection no longer vouches for them — an audit record, a message on a queue, a profile handed to another component. Ask for encryption when the body will cross something you do not want reading it. In a straightforward server-side relying party that reads the claims and throws the body away, the plain JSON form is the honest default, and adding a token format buys nothing but key management.