--- title: OAuth 2.0 description: Configure OAuth 2.0 with PingGateway as a client or resource server, using PingAM as the authorization server component: pinggateway version: 2024.11 page_id: pinggateway:gateway-guide:oauth2 canonical_url: https://docs.pingidentity.com/pinggateway/2026/gateway-guide/oauth2.html llms_txt: https://docs.pingidentity.com/pinggateway/llms.txt docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md revdate: 2026-06-02T11:29:35Z keywords: ["Configuration", "OAuth 2.0", "Authorization", "Scripts", "Certificates", "Keystores", "Truststores", "Passwords"] superseded_by: https://docs.pingidentity.com/pinggateway/2026/gateway-guide/oauth2.html section_ids: oauth2-introduction: OAuth 2.0 concepts oauth2-client: PingGateway as an OAuth 2.0 client about-oauth2-rs: PingGateway as an OAuth 2.0 resource server next_steps: Next steps --- # OAuth 2.0 As an authorization server, PingGateway *authenticates* resource owners and obtains their *authorization* to return access tokens to clients. Before you configure OAuth 2.0 in your environment, familiarize yourself with the [OAuth 2.0 authorization framework](https://www.rfc-editor.org/info/rfc6749) and related standards. ## OAuth 2.0 concepts RFC 6749, the [OAuth 2.0 authorization framework](https://www.rfc-editor.org/info/rfc6749) lets a third-party application obtain limited access to a resource (usually user data) on behalf of the resource owner or the application itself. The main actors in the OAuth 2.0 authorization framework are the following: | Actor | Description | | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Resource owner (RO)** | The owner of the resource. For example, a user who stores their photos in a photo-sharing service.The resource owner uses a *user-agent*, usually a web-browser, to communicate with the client. | | **Client** | The third-party application that wants to access the resource. The client makes requests on behalf of the resource owner and with their authorization. For example, a printing service that needs to access the resource owner's photos to print them.Learn more from [PingGateway as an OAuth 2.0 client](#oauth2-client). | | **Authorization server (AS)** | The authorization service that authenticates the resource owner and/or the client, issues access tokens to the client, and tracks their validity. Access tokens prove that the resource owner authorizes the client to act on their behalf over specific resources for a limited period of time.PingOne Advanced Identity Cloud or PingAM can act as an authorization server. | | **Resource server (RS)** | The service hosting the protected resources. For example, a photo-sharing service. The resource server must be able to validate the tokens issued by the authorization server.Learn more from [PingGateway as an OAuth 2.0 resource server](#about-oauth2-rs). | ## PingGateway as an OAuth 2.0 client PingGateway as an OAuth 2.0 client supports the OAuth 2.0 filters and flows in the following table: | Filter | OAuth 2.0 flow | Description | | --------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [AuthorizationCodeOAuth2ClientFilter](../reference/AuthorizationCodeOAuth2ClientFilter.html)(previously named OAuth2ClientFilter) | [Authorization Code Grant](https://datatracker.ietf.org/doc/html/rfc6749#section-4.1) | This filter requires the user agent to authorize the request interactively to obtain an access token and optional ID token.The access token is maintained only for the OAuth 2.0 session, and is valid only for the configured scopes.This filter can act as an OpenID Connect relying party or as an OAuth 2.0 client. Use for Web applications running on a server. | | [ResourceOwnerOAuth2ClientFilter](../reference/ResourceOwnerOAuth2ClientFilter.html) | [Resource Owner Password Credentials Grant](https://datatracker.ietf.org/doc/html/rfc6749#section-4.3) | According to information in the [The OAuth 2.0 Authorization Framework](https://datatracker.ietf.org/doc/html/rfc6749#section-10.7), minimize use of this grant type and use other grant types when possible.This filter supports the transformation of client credentials and user credentials to obtain an access token from the Authorization Server. It injects the access token into the inbound request as a Bearer Authorization header. The access token is valid only for the configured scopes.Use for clients trusted with the resource owner credentials. | | [ClientCredentialsOAuth2ClientFilter](../reference/ClientCredentialsOAuth2ClientFilter.html) | [Client Credentials Grant](https://datatracker.ietf.org/doc/html/rfc6749#section-4.4) | This filter is similar to the Resource Owner Password Credentials grant type, but the resource owner is not part of the flow and the client accesses only information relevant to itself.Use when the client is the resource owner, or the client doesn't act on behalf of the resource owner. | ## PingGateway as an OAuth 2.0 resource server The following image illustrates the steps for a client application to access a user's protected resources, with AM as the Authorization Server and PingGateway as the resource server: ![PingGateway handles OAuth 2.0 requests as an OAuth 2.0 resource server.](_images/resource-server.svg)Figure 1. PingGateway as an OAuth 2.0 resource server handling OAuth 2.0 requests * The application obtains an *authorization grant*, representing the resource owner's consent. Learn more about the different OAuth 2.0 grant mechanisms supported by AM in the AM documentation on [OAuth 2.0 grant flows](https://docs.pingidentity.com/pingam/7.5/am-oauth2/oauth2-implementing-flows.html). * The application authenticates to the Authorization Server and requests an *access token*. The Authorization Server returns an access token to the application. An OAuth 2.0 access token is an opaque string issued by the authorization server. When the client interacts with the resource server, the client presents the access token in the `Authorization` header. For example: ```http Authorization: Bearer 7af...da9 ``` Access tokens are the credentials to access protected resources. The advantage of access tokens over passwords or other credentials is that access tokens can be granted and revoked without exposing the user's credentials. The access token represents the authorization to access protected resources. Because an access token is a bearer token, anyone who has the access token can use it to get the resources. Access tokens must therefore be protected, so that requests involving them go over HTTPS. In OAuth 2.0, the token scopes are strings that identify the scope of access authorized to the client, but can also be used for other purposes. * The application supplies the access token to the resource server, which then resolves and validates the access token by using an access token resolver, as described in [Access token resolvers](../reference/AccessTokenResolvers.html). If the access token is valid, the resource server permits the client access to the requested resource. The [OAuth2ResourceServerFilter](../reference/OAuth2ResourceServerFilter.html) grants access to a resource by using an OAuth 2.0 access token from the HTTP Authorization header of a request. When auditing is enabled, OAuth 2.0 token tracking IDs can be logged in access audit events for routes that contain an OAuth2ResourceServerFilter. Learn more in [Audit the deployment](../maintenance-guide/auditing.html) and [Audit framework](../reference/AuditFramework.html). ## Next steps * [Validate access tokens with introspection](oauth2-rs-introspect.html) * [Script required scopes](oauth2-rs-script-scopes.html) * [Validate stateless access tokens](oauth2-rs-stateless.html) * [With JwkSetSecretStore](oauth2-rs-stateless-signed-sat.html) * [Signed tokens with KeyStoreSecretStore](oauth2-rs-stateless-signed-ksss.html) * [Encrypted tokens with KeyStoreSecretStore](oauth2-rs-stateless-encrypted.html) * [Mutual TLS](oauth2-rs-introspect-mtls.html) * [mTLS with client certificates](oauth2-rs-introspect-mtls-certificate.html) * [mTLS with trusted headers](oauth2-rs-introspect-mtls-header.html) * [OAuth 2.0 context for authentication](oauth2-rs-pwreplay.html) * [Cache access tokens](oauth2-rs-cacheatr.html) * [Client credentials grant](oauth2-clientcredentials.html) * [Resource owner password credentials grant](oauth2-resourceowner.html)