--- title: OAuth authorization server metadata endpoint description: The OAuth authorization server metadata endpoint provides configuration information that OAuth clients need to interface with PingFederate using the OAuth 2.0 protocol. component: pingfederate version: 13.1 page_id: pingfederate:developers_reference_guide:pf_oauth_authorization_server_metadata_endpoint canonical_url: https://docs.pingidentity.com/pingfederate/13.1/developers_reference_guide/pf_oauth_authorization_server_metadata_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: September 14, 2023 section_ids: endpoint-well-knownoauth-authorization-server: "Endpoint: /.well-known/oauth-authorization-server" notable-metadata-parameters: Notable metadata parameters --- # OAuth authorization server metadata endpoint The OAuth authorization server metadata endpoint provides configuration information that OAuth clients need to interface with PingFederate using the OAuth 2.0 protocol. PingFederate supports OAuth 2.0 authorization server metadata (). This lets OAuth clients retrieve relevant endpoints and other details about features that PingFederate supports. The information returned by the OAuth authorization server metadata endpoint is controlled by the `openid-configuration.template.json` template file. You can customize that file to suit OAuth and OpenID Connect use cases simultaneously. ## Endpoint: /.well-known/oauth-authorization-server The OAuth authorization server metadata endpoint is `/.well-known/oauth-authorization-server`. This public endpoint accepts HTTP GET requests without authentication. When PingFederate is configured with a virtual issuer and a path, the patterns for the OpenID Connect and OAuth authorization server metadata endpoints differ from one another because they are based on different specifications. The OAuth 2.0 metadata specification requires the issuer path to be after `/.well-known/oauth-authorization-server`. The OpenID Connect metadata specification requires the issuer path to be before `/.well-known/openid-configuration`. For example, if the virtual issuer's host name is `sso.example.com` and the path is `/issuer1`, which produces `https://sso.example.com/issuer1`, then: * the OAuth authorization server metadata endpoint is ``` https://sso.example.com/.well-known/oauth-authorization-server/issuer1 ``` * the OpenID Connect metadata endpoint is ``` https://sso.example.com/issuer1/.well-known/openid-configuration ``` The response from the OAuth authorization server metadata endpoint is like the response from the OpenID Connect metadata endpoint but doesn't include details specific to OpenID Connect. You can customize the response for this endpoint. Learn more in [Customizing the OpenID Provider configuration endpoint response](../administrators_reference_guide/pf_customiz_config_endpoint_response.html#customizing_the_openid_provider_configuration_endpoint_response). The following code block shows an example of a response from the OAuth authorization server metadata endpoint. ```shell $ curl -s https://localhost:9031/.well-known/oauth-authorization-server|python -m json.tool { "authorization_endpoint": "https://localhost:9031/as/authorization.oauth2", "backchannel_authentication_endpoint": "https://localhost:9031/as/bc-auth.ciba", "backchannel_authentication_request_signing_alg_values_supported": [ "RS256", "RS384", "RS512", "ES256", "ES384", "ES512", "PS256", "PS384", "PS512" ], "backchannel_token_delivery_modes_supported": [ "poll", "ping" ], "backchannel_user_code_parameter_supported": true, "code_challenge_methods_supported": [ "plain", "S256" ], "claims_supported": [ "address", "birthdate", "email", "email_verified", "family_name", "gender", "given_name", "locale", "middle_name", "name", "nickname", "phone_number", "phone_number_verified", "picture", "preferred_username", "profile", "sub", "updated_at", "website", "zoneinfo" ], "device_authorization_endpoint": "https://localhost:9031/as/device_authz.oauth2", "grant_types_supported": [ "implicit", "authorization_code", "refresh_token", "password", "client_credentials", "urn:pingidentity.com:oauth2:grant_type:validate_bearer", "urn:ietf:params:oauth:grant-type:jwt-bearer", "urn:ietf:params:oauth:grant-type:saml2-bearer", "urn:ietf:params:oauth:grant-type:device_code", "urn:openid:params:grant-type:ciba" ], "introspection_endpoint": "https://localhost:9031/as/introspect.oauth2", "issuer": "https://localhost:9031", "jwks_uri": "https://localhost:9031/pf/JWKS", "ping_end_session_endpoint": "https://localhost:9031/idp/startSLO.ping", "ping_revoked_sris_endpoint": "https://localhost:9031/pf-ws/rest/sessionMgmt/revokedSris", "registration_endpoint": "https://localhost:9031/as/clients.oauth2", "request_object_signing_alg_values_supported": [ "RS256", "RS384", "RS512", "ES256", "ES384", "ES512", "PS256", "PS384", "PS512" ], "request_parameter_supported": true, "request_uri_parameter_supported": false, "response_modes_supported": [ "fragment", "query", "form_post" ], "response_types_supported": [ "code", "token", "id_token", "code token", "code id_token", "token id_token", "code token id_token" ], "revocation_endpoint": "https://localhost:9031/as/revoke_token.oauth2", "scopes_supported": [ "address", "phone", "edit", "openid", "profile", "admin", "email" ], "token_endpoint": "https://www.example.com:9031/as/token.oauth2", "token_endpoint_auth_methods_supported": [ "client_secret_basic", "client_secret_post", "private_key_jwt" "none" ], "token_endpoint_auth_signing_alg_values_supported": [ "RS256", "RS384", "RS512", "ES256", "ES384", "ES512", "PS256", "PS384", "PS512" ] } ``` ## Notable metadata parameters * CIBA user code support The `backchannel_user_code_parameter_supported` parameter indicates whether the default CIBA request policy supports user codes, which are an optional feature in the CIBA specification.In the previous example, because the **User Code PCV** field is configured with a Password Credential Validator instance in the default CIBA request policy, the value of the `backchannel_user_code_parameter_supported` parameter is `true`. For more information, see [OpenID Connect Client Initiated Backchannel Authentication Flow](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html) and [Defining a request policy](../administrators_reference_guide/help_cibapolicymanagementtasklet_cibapolicymanagementstate.html). * Identity chaining support The `identity_chaining_requested_token_types_supported` parameter indicates which token types an identity provider authorization server can issue for identity chaining. For ID-JAG support, this parameter includes `urn:ietf:params:oauth:token-type:id-jag`. The `authorization_grant_profiles_supported` parameter indicates which grant profiles a resource authorization server can process for identity chaining. For ID-JAG support, this parameter includes `urn:ietf:params:oauth:grant-profile:id-jag`. * Digital signature algorithms The `backchannel_authentication_request_signing_alg_values_supported`, `token_endpoint_auth_signing_alg_values_supported`, and `request_object_signing_alg_values_supported` parameters provide lists of supported algorithms to process digital signatures. In this example, because PingFederate is integrated with a hardware security module (HSM) and configured to use static keys for OAuth and OpenID Connect, the endpoint includes additional RSASSA-PSS digital signature algorithms (`PS256`, `PS384`, and `PS512`) in its response. You can find more information on HSM integration and static keys in [Supported hardware security modules](../getting_started_with_pingfederate/pf_supported_hardware_security_modules.html) and [Keys for OAuth and OpenID Connect](../administrators_reference_guide/help_jwksendpointtasklet_jwksendpointkeysstate.html), respectively. Deploying PingFederate to run on a Java 8 or a Java 11 environment will have the same result. * JWKS endpoint The JWKS endpoint, `jwks_uri`, returns a set of public keys for OAuth and OpenID Connect. Clients can use this information to verify the integrity of asymmetrically-signed ID tokens, JSON web tokens (JWTs) for client authentication, and OpenID Connect request objects. * Scopes The OP configuration endpoint returns all common static scopes and common scope groups but not exclusive static scopes, exclusive scope groups, common dynamic scopes, or exclusive dynamic scopes by default. The response can be customized by editing a template file to include or exclude individual scopes and scope groups. * Token endpoint The token endpoint, `token_endpoint`, is used by clients to obtain access tokens and refresh tokens if applicable.In the previous example, because the **Token Endpoint Base URL** is set to `https://www.example.com:9031` in the **System > OAuth Settings > Authorization Server Settings** window, the `token_endpoint` value is set to . For more information, see [Configuring authorization server settings](../administrators_reference_guide/help_authorizationserversettingstasklet_oauthauthorizationserversettingsstate.html) and [Token endpoint](pf_token_endpoint.html).