Category: OAuth & OIDC

UserInfo Endpoint

Also known as: UserInfo, /userinfo endpoint

Simply put

The UserInfo Endpoint is a service defined by OpenID Connect that an application can call to retrieve information about a signed-in user, such as their name or email. The application presents an access token it received during sign-in, and the endpoint returns the user details that the user consented to share. It is often called automatically by OpenID Connect client libraries after authentication completes.

Formal definition

In OpenID Connect Core 1.0, the UserInfo Endpoint is an OAuth 2.0 protected resource that returns claims about the authenticated end-user. A client accesses it by presenting a valid OAuth 2.0 access token (typically obtained via an OIDC flow), and the endpoint returns the set of consented claims associated with that token's authorization. The claims returned are governed by the scopes granted and the user's consent, and in practice the exact claim set varies by provider configuration and profile (for example, enabling OIDC-conformant behavior can change which claims are returned). Note the distinction between the UserInfo Endpoint response, which conveys profile claims, and the ID Token, which is the primary artifact asserting the authentication event itself; the UserInfo Endpoint supplements rather than replaces the ID Token. Response formats and whether responses are signed or encrypted depend on the provider and the requested configuration.

Why it matters

The UserInfo Endpoint gives applications a standardized way to retrieve profile claims about an authenticated user without embedding all of that information in the ID Token. This matters because it lets clients keep tokens smaller and fetch up-to-date user attributes on demand, while the ID Token remains the primary artifact asserting the authentication event. Confusing the two can lead to design mistakes: relying on the UserInfo response as proof of authentication, rather than validating the ID Token, misplaces trust in an endpoint whose purpose is to supplement profile data rather than assert the authentication event itself.

Because the endpoint is an OAuth 2.0 protected resource, the claims it returns are governed by the scopes granted and the user's consent. Engineers integrating OpenID Connect need to understand that the exact claim set is not fixed by the standard alone; it varies by provider configuration and profile. For example, enabling OIDC-conformant behavior on some providers changes which claims are returned, which can silently break integrations that assumed a particular attribute would always be present. Treating the UserInfo response as a stable, guaranteed schema across providers is a common source of brittle integrations.

Handling the access token used to call the UserInfo Endpoint also carries security weight. That token authorizes retrieval of the user's consented profile data, so its scope, storage, and transmission should be managed with the same care applied to any credential granting access to personal information.

Who it's relevant to

IAM and application engineers integrating OpenID Connect

Engineers wiring applications to an OIDC provider need to know when their client library calls the UserInfo Endpoint automatically and which claims to expect. Because the returned claim set varies by scopes, consent, provider configuration, and profile settings such as OIDC-conformant behavior, they should avoid assuming a fixed schema and should validate the ID Token separately for the authentication event rather than treating the UserInfo response as proof of authentication.

Security architects

Architects designing federated authentication flows should account for how the access token that authorizes UserInfo calls is issued, scoped, stored, and transmitted, since it grants retrieval of a user's consented profile data. They also need to decide whether signed or encrypted UserInfo responses are required, recognizing that signing addresses integrity while encryption addresses confidentiality, and that support depends on the provider and configuration.

Identity provider administrators

Administrators configuring an OIDC provider control which claims the UserInfo Endpoint returns through scope definitions, consent settings, and profile options. Changes such as enabling OIDC-conformant behavior can reduce or alter the claims returned to clients, so administrators should communicate configuration changes that affect downstream integrations.

Inside UserInfo Endpoint

OAuth 2.0 Access Token Requirement

The UserInfo endpoint is a protected resource that requires a valid OAuth 2.0 access token, typically presented as a Bearer token in the Authorization header. The token must have been issued with sufficient scope to authorize retrieval of the requested claims.

Claims Response

The endpoint returns claims about the authenticated end-user, such as sub, name, email, and other profile attributes. The specific claims returned typically depend on the scopes granted (for example, profile, email, address, phone) during the OIDC authentication request.

Subject (sub) Claim

In most deployments the response includes the sub claim identifying the end-user. Per OIDC Core, the sub value returned by the UserInfo endpoint should match the sub in the ID token to prevent token substitution; clients are advised to verify this correspondence.

Response Formats

The UserInfo response is commonly returned as a JSON object. Depending on configuration, it may instead be returned as a signed and/or encrypted JWT when the client is registered for signed or encrypted UserInfo responses.

Role Within OpenID Connect

The UserInfo endpoint is part of OpenID Connect, the authentication layer built on top of OAuth 2.0. It supplements the identity information already conveyed in the ID token by allowing clients to fetch additional user claims at runtime.

Common questions

Answers to the questions practitioners most commonly ask about UserInfo Endpoint.

Is calling the UserInfo endpoint part of OAuth 2.0 authentication?

No. OAuth 2.0 is a delegated authorization framework and does not itself authenticate users. The UserInfo endpoint is defined by OpenID Connect (OIDC Core), the authentication layer built on top of OAuth 2.0. The endpoint returns claims about an already-authenticated end user, but the authentication event is represented by the ID token issued during the OIDC flow, not by the act of calling UserInfo. Treating a successful UserInfo response as proof of a fresh authentication conflates authorization-protected resource access with authentication and is not correct.

Does the UserInfo endpoint return the same thing as the ID token, making one of them redundant?

Not exactly. The ID token is a JWT asserting that authentication occurred, containing claims the OpenID Provider chose to include at issuance, and it is validated by the client. The UserInfo endpoint is an OAuth 2.0 protected resource that returns claims about the authenticated subject when queried with a valid access token. In many deployments the ID token carries a minimal set of claims and the client retrieves additional claims from UserInfo, though a provider may return overlapping claims in both. They serve different purposes: the ID token attests to the authentication event, while UserInfo is a queryable claims source. Whether either alone is sufficient depends on the deployment and the claims required.

What credential does a client present to call the UserInfo endpoint?

The client presents an access token, typically as a Bearer token in the Authorization header, as with any OAuth 2.0 protected resource. The access token must carry sufficient scope for the claims being requested; in most deployments the openid scope plus scopes such as profile or email govern which claims are returned. Note that the access token, not the ID token, is used here. The specific claims returned depend on the granted scopes, the provider's configuration, and any consent captured during authorization.

Should I validate the sub claim from UserInfo against the ID token?

Yes, when both are available in the same flow. OIDC guidance directs clients to verify that the sub value returned by the UserInfo endpoint matches the sub in the ID token before relying on the UserInfo claims. This mitigates the risk of associating claims with the wrong subject, for example if an access token from a different context were substituted. If the sub values do not match, the UserInfo response should not be used.

Can UserInfo responses be signed or encrypted rather than returned as plain JSON?

Depending on provider capability and client registration, UserInfo can return claims as plain JSON or as a signed and/or encrypted JWT. Signing provides integrity and origin assurance; encryption provides confidentiality. These are distinct protections, and a signed response is not encrypted. Support for signed or encrypted UserInfo responses varies by provider and must generally be negotiated through client registration metadata. If not configured, expect a plain JSON response over TLS.

How should clients handle claims freshness given that UserInfo returns current data?

The UserInfo endpoint returns claims as they exist at query time, which may differ from claims embedded in an ID token issued earlier. Clients that require up-to-date attribute values may query UserInfo rather than rely solely on ID token claims, subject to the access token remaining valid. However, this is a claims-retrieval mechanism, not a re-authentication or authorization decision point; if a decision requires a fresh authentication event or current authorization state, that must be obtained through the appropriate authentication flow or runtime enforcement (PDP/PEP), not inferred from a UserInfo call. Caching and refresh behavior depend on configuration and token lifetimes.

Common misconceptions

The UserInfo endpoint is a plain OAuth 2.0 feature usable for authenticating users.

The UserInfo endpoint is defined by OpenID Connect (the authentication layer on top of OAuth 2.0), not by OAuth 2.0 alone. OAuth 2.0 by itself is a delegated authorization framework and does not define user authentication or a standardized user-claims endpoint. Access to UserInfo is authorized by an access token, but the authentication event itself is represented by the ID token.

Because a UserInfo response can be a signed JWT, its contents are confidential.

Signing a JWT provides integrity and authenticity, not confidentiality. A signed-only UserInfo response is readable by anyone who obtains it. Confidentiality of claims requires encryption (for example an encrypted JWT response) and transport protection such as TLS, depending on configuration.

The UserInfo endpoint returns all of a user's attributes regardless of the request.

The claims returned typically depend on the scopes granted during authentication and on the deployment's configuration. A client generally receives only the claims authorized by the granted scopes, not the user's complete attribute set.

Best practices

Always call the UserInfo endpoint over TLS and present the access token as a Bearer token in the Authorization header rather than in a query parameter.

Verify that the sub claim returned by the UserInfo endpoint matches the sub in the ID token before associating the returned claims with the authenticated user, to guard against token substitution.

Request only the scopes needed for the claims your application requires, since the returned claims typically depend on the scopes granted.

Do not treat a successful UserInfo response as a fresh authentication event; rely on the ID token and its validation for authentication, and use UserInfo to supplement additional claims.

If claim confidentiality beyond transport encryption is required, configure signed and encrypted UserInfo (JWT) responses rather than assuming a signed response protects the contents.

Handle the response format defensively based on client registration, parsing JSON or a signed/encrypted JWT as configured, and validate signatures where JWT responses are used.