# Get user claims from UserInfo

When a user is authenticated, the access token can be associated with useful claims that your application can use for identity, personalization, and authorization-related logic. To retrieve these claims in a standard [OpenID Connect (OIDC)](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) way, call the [UserInfo (`/oidc/me`)](/openapi/user/oidc.openapi/other/oidcuserinfoget) endpoint.

UserInfo (`/oidc/me`) endpoint is typically called by your application backend after exchanging an authorization code for tokens, by a server-side web application after login, or by backend components acting on behalf of a logged-in user.

OIDC request methods
As defined by OIDC, UserInfo supports both [`GET` requests](/openapi/user/oidc.openapi/other/oidcuserinfoget) with the bearer token in the `Authorization` header and [`POST` requests](/openapi/user/oidc.openapi/other/oidcuserinfopost) with the token as the form-encoded `access_token` body parameter.

## Use cases

Get user claims from access token to:

- Retrieve user profile data after the user has already authenticated
- Fetch supported claims on demand instead of relying on the ID token alone
- Keep your integration aligned with the standard OIDC client pattern
- Return claims that depend on client configuration or what was requested during authentication


Choose between ID token, UserInfo, and Introspection
- **ID token**: Use it for identity claims returned directly by the login flow.
- **UserInfo** (`/oidc/me`): Use it to retrieve user claims after token exchange by calling the endpoint with the access token.
- **Introspection**: Use it to check whether an access token is still active and retrieve token metadata for backend or API decisions. If your service validates self-contained JWT access tokens locally, follow [Validate tokens](/guides/user/validate_tokens).


## How it works

When an OIDC authentication flow succeeds, Mosaic returns a JWT access token to your backend. Your backend then calls the UserInfo (`/oidc/me`) endpoint with that token to retrieve user claims. Your application can use the returned claims to create a session, personalize the experience, or support downstream logic.

This pattern is useful when your application needs a dedicated user profile response after login instead of relying only on the ID token payload.

```mermaid
sequenceDiagram
  participant B as Your backend
  participant M as Mosaic

  Note over B,M: OIDC authentication flow completed
  M-->>B: Return access token
  B->>M: Call `UserInfo` with access token
  M-->>B: Return user claims
  B-->>B: Use claims in app flow
```

The **response** contains claims about the end-user associated with the access token. In addition to the baseline UserInfo claims, the exact response depends on the granted scopes, client configuration, and any values requested through `claims.userinfo` in the original authorization request. It can include:

- User identifier claims such as `sub`
- Standard OIDC profile attributes such as `email`, `phone_number`, `fname`, and `lname`
- Authorization-related user claims such as `groups`, `roles`, and `permissions`
- Supported custom claims configured for the client or requested during authentication


The exact claim set can vary by integration. For example, some apps may request only basic profile claims, while others may also return app-specific data such as `custom_data` or `custom_app_data`, together with other supported custom claims configured for UserInfo. When authentication runs under a B2B context, the response identifies the organizations by automatically including the `org_id` (see [Org context (B2B)](/guides/orchestration/concepts/b2b)).

## Example

In the example below, the backend calls the [UserInfo (`/oidc/me`)](/openapi/user/oidc.openapi/other/oidcuserinfoget) endpoint at `https://api.transmitsecurity.io/cis/oidc/me` using the user access token returned by the [`/oidc/token`](/openapi/user/oidc.openapi/other/oidctoken) endpoint in the `Authorization: Bearer ACCESS_TOKEN` header. You can also call [`POST /oidc/me`](/openapi/user/oidc.openapi/other/oidcuserinfopost) and send the token as `access_token` in the form-encoded request body.

Base URL
If your Mosaic deployment uses a regional base URL or a custom domain, replace the host in the example above accordingly.

The actual response can differ from one client to another because scopes, requested claims, and client settings affect which claims are returned. For example:

```json
{
  "sub": "ufnbfps4ki0qm1twdo79g",
  "email": "user@acme.com",
  "email_verified": true,
  "fname": "Avery",
  "lname": "Taylor",
  "groups": [
    "premium-customers"
  ],
  "role_values": [
    "customer",
    "vip"
  ],
  "custom_data": {
    "tier": "gold"
  }
}
```