---
title: UserInfo endpoint
description: OAuth clients can present access tokens to the UserInfo endpoint to retrieve additional information about the resource owners.
component: pingfederate
version: 13.1
page_id: pingfederate:developers_reference_guide:pf_userinfo_endpoint
canonical_url: https://docs.pingidentity.com/pingfederate/13.1/developers_reference_guide/pf_userinfo_endpoint.html
llms_txt: https://docs.pingidentity.com/pingfederate/llms.txt
docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md
revdate: April 14, 2025
section_ids:
  exampleuserinfo-endpoint-idpuserinfo-openid: ExampleUserInfo endpoint /idp/userinfo.openid
  self-contained-tokens: Self-contained tokens
  related-links: Related links
---

# UserInfo endpoint

OAuth clients can present access tokens to the `UserInfo` endpoint to retrieve additional information about the resource owners.

You can customize the amount of information presented by the endpoint by using OpenID Connect policies. Information can include specification-defined attributes (standard attributes) and non-standard attributes. Scopes, authorized by the users, also determine the attributes to be returned.

This endpoint accepts HTTP GET requests without parameters. Clients must present valid access tokens for authentication.

## ExampleUserInfo endpoint /idp/userinfo.openid

The following example shows a request to `UserInfo` endpoint `/idp/userinfo.openid` and the response. The self-contained access token in the request's Authorization header is truncated for readability.

```shell
$ curl -s https://localhost:9031/idp/userinfo.openid -H 'Authorization: Bearer eyJ...9-g'|python -m json.tool

{
    "email": "auser@example.com",
    "phone_number": "(555) 555-5555",
    "phone_number_verified": true,
    "sub": "joe"
}
```

If the access token presented is not valid, PingFederate returns `401 Unauthorized`.

|   |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
| - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|   | To use a demonstrating proof-of-possession (DPoP)-bound access token, use the DPoP authentication scheme in the Authorization header and include a DPoP Proof JWT in the DPoP header. Learn more in the [OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer](https://datatracker.ietf.org/doc/rfc9449/) specification and the description of the PingFederate DPoP settings in [Configuring authorization server settings](../administrators_reference_guide/help_authorizationserversettingstasklet_oauthauthorizationserversettingsstate.html). |

## Self-contained tokens

If clients using self-contained access tokens are expected to contact the `UserInfo` endpoint, consider the following implications:

* Client ID Claim Name

  This field's default value is `client_id`. When this field is configured with a value, PingFederate includes the client ID of the requesting client as a claim in the self-contained tokens. The claim name is the value of the **Client ID Claim Name** field.

  If the field value is empty, PingFederate will not include the client ID of the requesting client in the self-contained tokens. In this scenario, the access token manager (ATM) instance used by the default OpenID Connect policy must remain accessible to all clients, or clients using self-contained access tokens issued by this ATM instance will not be able to retrieve additional claims from the UserInfo endpoint. Instead, they receive an HTTP status code `401 Unauthorized` from PingFederate. Learn more in [Defining access control](../administrators_reference_guide/help_beareraccesstokenmgmtplugintasklet_atmaccesscontrolsettingsstate.html).

  Learn more about the **Client ID Claim Name** in [Configuring an access token management instance](../administrators_reference_guide/pf_configuring_access_token_management_instance.html).

* Scope Claim Name

  This field's default value is `scope`. When this field is configured with a value, PingFederate includes the requested scopes as a claim in the self-contained tokens. The claim name is the value of the **Scope Claim Name** field.

  If the field value is empty, PingFederate will not include any scope information in the self-contained token, and clients using self-contained access tokens issued by this ATM instance will not be able to retrieve additional claims from the UserInfo endpoint. Instead, they receive an HTTP status code `403 Forbidden` from PingFederate.

  Learn more about the **Scope Claim Name** in [Configuring an access token management instance](../administrators_reference_guide/pf_configuring_access_token_management_instance.html).

## Related links

* [Token models and management](../introduction_to_pingfederate/pf_token_model_and_manage.html)

* [Configuring an access token management instance](../administrators_reference_guide/pf_configuring_access_token_management_instance.html)

* [Configuring OpenID Connect policies](../administrators_reference_guide/pf_configuring_oidc_policies.html)