UserInfo Endpoint

The primary function of the endpoint is to return a JSON object containing claims about the authenticated user, such as sub (subject identifier), name, email, and picture. These claims are requested via the scope parameter during the initial authorization request (e.g., scope=openid profile email). The endpoint provides a machine-readable, standardized way for a Relying Party (client application) to retrieve verified user attributes after authentication.

Access to the UserInfo Endpoint is strictly protected. The client must present the Access Token obtained during the OAuth 2.0/OIDC flow in the HTTP Authorization header using the Bearer token scheme (Authorization: Bearer <access_token>). The authorization server validates this token to ensure the request is authorized and returns claims scoped to that specific token. This mechanism ensures that user data is only disclosed to clients with a valid grant.

A critical security and consistency feature is the verification of the sub claim. The subject identifier returned by the UserInfo Endpoint MUST be identical to the sub claim found in the ID Token issued for the same authentication session. This prevents identity mix-ups and ensures the client is receiving information about the same user it authenticated, maintaining integrity across tokens and API responses.

The UserInfo Endpoint is a protected resource as defined by OAuth 2.0. Its implementation on the authorization server must validate the Access Token's scope, audience, and expiration. The data returned can be dynamic, reflecting the most current user profile information stored by the OpenID Provider. It is distinct from the static claims in an ID Token, which are signed at the time of issuance.

The endpoint must return claims in a JSON object with the Content-Type header application/json. The response body structure is defined by the OIDC specification. For JWT-based responses (less common), the endpoint can return a signed or encrypted JSON Web Token (JWT) as the claim set, using the Content-Type application/jwt. This provides an additional layer of security through cryptographic verification of the response itself.

The primary use case is for client applications to enrich user profiles after authentication. For example, after a user logs in via "Sign in with Google," the app calls Google's UserInfo Endpoint to fetch the user's full name and profile picture to display in a welcome message. It decouples authentication from user data retrieval, allowing apps to request only the data they need, when they need it, adhering to the principle of least privilege.

The primary function of a UserInfo endpoint is to return the state of a user's position within a staking contract or liquidity pool. A typical call returns a structured object containing:

• amount: The principal amount of tokens the user has deposited (e.g., LP tokens).
• rewardDebt: An accounting value used to calculate pending rewards, often based on accumulated rewards per share.
• pendingRewards: The amount of reward tokens (e.g., governance or fee tokens) currently claimable by the user.

The MasterChef contract pattern, popularized by SushiSwap and widely forked, cemented the userInfo function as a standard. It maps a user's address and a pool ID (pid) to a UserInfo struct. This pattern is fundamental for yield farming and liquidity mining programs, allowing frontends and integrators to display real-time staking data and accrued yields for users.

DeFi frontends and dashboards like DeBank or Zapper rely heavily on calling userInfo endpoints across multiple protocols to aggregate a user's Total Value Locked (TVL) and pending yields. This enables features like:

• A unified portfolio view of all staked assets.
• Automated reward tracking and claim notifications.
• Calculation of Annual Percentage Yield (APY) based on the user's specific share of the pool.

Analytics platforms and risk engines use the UserInfo endpoint to monitor protocol health and user exposure. By querying this data, they can:

• Track the distribution of staked assets and identify concentration risk.
• Monitor reward emission rates and sustainability.
• Build models for impermanent loss based on a user's specific LP position history.

Automated smart contracts or keeper networks call userInfo to check conditions for executing transactions. Common automation triggers include:

• Auto-compounding: When pendingRewards reach a threshold, a bot claims and re-stakes them.
• Position management: Monitoring the amount to trigger rebalancing or exit strategies based on predefined rules.
• Reward optimization: Moving funds between pools based on real-time reward rates fetched from multiple userInfo calls.

While the core fields are consistent, many protocols extend the UserInfo struct to include protocol-specific data. Examples include:

• Lock-up periods: Timestamps for when deposited funds become withdrawable.
• Boost multipliers: Factors that increase reward rates based on ve-token governance models.
• Fee tier information: For concentrated liquidity AMMs like Uniswap V3, detailing the price range of the user's position.

The UserInfo endpoint is a standardized part of the OAuth 2.0 authorization framework, specifically defined in the OpenID Connect (OIDC) extension. It provides a protected resource that returns claims about the authenticated end-user, such as their name or email address, using a valid access token.

• Purpose: To retrieve standardized identity information after authorization.
• Standard: Defined in the OpenID Connect Core 1.0 specification.
• Flow: Client applications call this endpoint after obtaining an access token from the authorization server.

Understanding the distinction between these tokens is crucial for using the UserInfo endpoint correctly.

• Access Token: A credential used to access protected resources like the UserInfo endpoint. It is an opaque string or a JWT (JSON Web Token).
• ID Token: A JWT issued by the OpenID Provider (OP) that contains claims about the user's authentication event and identity. While an ID token contains user info, the UserInfo endpoint provides a more scalable way to fetch potentially larger or more dynamic profile data.

The UserInfo endpoint is typically accessed with an access token, not an ID token.

The data returned by the UserInfo endpoint is composed of claims—statements about the user. Which claims are returned is controlled by scopes requested during the initial OAuth authorization.

• Standard Claims: Predefined claims like name, email, and sub (subject identifier).
• Custom Claims: Additional, implementation-specific claims.
• Scope Example: Requesting the profile scope typically grants access to name-related claims, while the email scope grants access to the email and email_verified claims.

The endpoint's response is a JSON object containing the authorized claims for the user.

The Authorization Server is the central OAuth 2.0 component that issues access tokens to client applications after successfully authenticating the resource owner (user) and obtaining authorization. The UserInfo endpoint is hosted by this server or a closely associated Resource Server.

• Functions: Authenticates users, obtains consent, and issues tokens.
• Relation to UserInfo: The AS validates the access token presented to the UserInfo endpoint to ensure it has the correct audience (aud) and scopes before returning the user's claims.
• Examples: Auth0, Okta, Keycloak, and proprietary identity providers all implement an authorization server with a UserInfo endpoint.

The JSON Web Token (JWT) is a compact, URL-safe token format defined in RFC 7519, commonly used for access tokens and ID tokens in OAuth/OpenID Connect flows.

• Structure: A JWT consists of three parts: Header, Payload (claims), and Signature.
• Self-Contained: JWTs can carry verifiable claims within themselves, reducing the need to query an endpoint for basic info.
• Connection to UserInfo: While an ID Token is always a JWT, an access token used to call the UserInfo endpoint may also be a JWT. The UserInfo endpoint itself returns a plain JSON object, not a JWT.

OpenID Connect 1.0 is a simple identity layer built on top of the OAuth 2.0 protocol. It standardizes how clients can verify the identity of an end-user and obtain basic profile information.

• Core Component: The UserInfo endpoint is one of the three standard endpoints in OIDC, alongside the Authorization Endpoint and Token Endpoint.
• Authentication vs. Authorization: OIDC adds authentication (proving "who you are") to OAuth's authorization (granting "access to something").
• Standardization: Defines the exact JSON structure and standard claims for the UserInfo endpoint response, ensuring interoperability between different identity providers and applications.