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) way, call the UserInfo (/oidc/me) 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.
As defined by OIDC, UserInfo supports both GET requests with the bearer token in the Authorization header and POST requests with the token as the form-encoded access_token body parameter.
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
- 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.
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.
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, andlname - Authorization-related user claims such as
groups,roles, andpermissions - 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)).
In the example below, the backend calls the UserInfo (/oidc/me) endpoint at https://api.transmitsecurity.io/cis/oidc/me using the user access token returned by the /oidc/token endpoint in the Authorization: Bearer ACCESS_TOKEN header. You can also call POST /oidc/me and send the token as access_token in the form-encoded request body.
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:
{
"sub": "ufnbfps4ki0qm1twdo79g",
"email": "user@acme.com",
"email_verified": true,
"fname": "Avery",
"lname": "Taylor",
"groups": [
"premium-customers"
],
"role_values": [
"customer",
"vip"
],
"custom_data": {
"tier": "gold"
}
}