UserInfo 端点

The ID token proves who the user is, but to keep it small it may carry only a few claims. The UserInfo endpoint is an OAuth2-protected resource that returns additional claims about the currently authenticated user.

UserInfo is not part of the token endpoint — it is a normal protected API. You call it with the access token obtained during the OIDC flow, presented as a Bearer token.

Its URL is published in the provider's discovery document under userinfo_endpoint.

Send a GET (or POST) with the access token in the Authorization header.

The response is a JSON object of claims. It must include the sub claim, which must equal the sub in the ID token to prevent token substitution.

Which claims are returned depends on the scopes granted during authorization:

• profile — name, picture, locale, etc.
• email — email, email_verified.
• address — postal address.
• phone — phone_number, phone_number_verified.

Always confirm the sub from UserInfo matches the sub in the validated ID token. Otherwise an attacker could swap an access token issued for a different user.

By default UserInfo returns plain JSON. Providers can also return a signed JWT (set via userinfo_signed_response_alg) so the client can verify integrity, and even an encrypted JWT for confidentiality.

When to use which?

• Put stable, identity-critical claims in the ID token (sub, auth_time).
• Fetch large or changeable profile data from UserInfo as needed.

This keeps the ID token compact while still giving rich profile access.

UserInfo data can change (a user updates their name). Avoid caching it indefinitely; refresh it on login or when you need current values, balancing freshness against extra network calls.

If the access token is expired or invalid, UserInfo returns a 401 with a WWW-Authenticate: Bearer error="invalid_token" header. Handle this by refreshing the token or re-authenticating.

The UserInfo endpoint returns additional user claims using the access token.

• It is a protected resource, discovered via userinfo_endpoint.
• Returned claims depend on granted scopes.
• Always verify its sub matches the ID token's sub.
• Responses can be plain JSON or signed/encrypted JWTs.