--- title: Configuring JavaScript apps for Pushed Authorization Requests description: PingOne PingOne Advanced Identity Cloud PingAM JavaScript component: orchsdks page_id: orchsdks:oidc:use-cases/par/javascript canonical_url: https://developer.pingidentity.com/orchsdks/oidc/use-cases/par/javascript.html llms_txt: https://developer.pingidentity.com/orchsdks/llms.txt docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md revdate: Thu, 19 Jun 2026 00:00:00 +0000 keywords: ["OAuth 2.0", "OpenID Connect", "Pushed Authorization Requests", "PAR", "RFC 9126", "SDK", "JavaScript", "TypeScript"] section_ids: before_you_begin: Before you begin configuring_an_oidc_client_for_par_in_javascript: Configuring an OIDC client for PAR in JavaScript implementing_par_with_background_authorization: Implementing PAR with background authorization adding_data_to_par_requests: Adding data to PAR requests learn_more: Learn more --- # Configuring JavaScript apps for Pushed Authorization Requests [icon: circle-check, set=far]PingOne [icon: circle-check, set=far]PingOne Advanced Identity Cloud [icon: circle-check, set=far]PingAM [icon: js, set=fab]JavaScript You can configure JavaScript apps built with the Orchestration SDK to use [Pushed Authorization Requests (PAR, RFC 9126)](https://datatracker.ietf.org/doc/html/rfc9126) for OIDC sign-on. When PAR is enabled, the SDK sends the OIDC authorization parameters to the server's `/par` endpoint before the browser redirect. The server returns a short-lived `request_uri`. The browser is then redirected to the `/authorize` endpoint using only that reference, keeping authorization parameters out of browser history and proxy logs. ## Before you begin You need to prepare your authorization server to support PAR. Select your server from the options below and complete the tasks before proceeding to configure your application. * PingOne * PingOne Advanced Identity Cloud * PingAM Ensure your PingOne OAuth 2.0 application is already configured for OIDC sign-on before enabling PAR. > **Collapse: Task 1. Configure a public OAuth 2.0 client for PAR** > > PingOne supports PAR for OIDC sign-on without any additional server configuration. > > By default, PingOne accepts both standard and PAR authorization requests. > > Optionally, you can require all authorization requests to use PAR by enabling Require Pushed Authorization Request on the Configuration tab of your PingOne application. > > To register a *public* OAuth 2.0 client application in PingOne for use with the Orchestration SDK for JavaScript, follow these steps: > > 1. Log in to your PingOne administration console. > > 2. In the left panel, navigate to Applications > Applications. > > 3. Next to the Applications label, click the plus icon ([icon: plus, set=fa]). > > PingOne displays the Add Application panel. > > 4. In Application Name, enter a name for the profile, for example `sdkPublicClient` > > 5. Select OIDC Web App as the Application Type, and then click Save. > > 6. On the Configuration tab, click the pencil icon ([icon: pencil, set=fa]). > > 1. In Grant Type, select the following: > > `Authorization Code` > > `Refresh Token` > > 2. In Redirect URIs, enter the following: > > `https://localhost:8443/callback.html` > > | | | > | - | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | > | | Also add any other URLs where you host SDK applications.Failure to add redirect URLs that exactly match your client app's values can cause PingOne to display an error message such as `Redirect URI mismatch` when attempting to end a session by redirecting from the SDK. | > > 3. In Token Endpoint Authentication Method, select `None`. > > 4. In Signoff URLs, enter the following: > > `https://localhost:8443` > > | | | > | - | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | > | | Also add any other URLs that redirect users to PingOne to end their session.Failure to add sign off URLs that exactly match your client app's values can cause PingOne to display an error message such as `invalid post logout redirect URI` when attempting to end a session by redirecting from the SDK. | > > 5. In CORS Settings, in the drop-down select Allow specific origins, and in the Allowed Origins field, enter the URL where you will be running the sample app. > > For example, `https://localhost:8443` > > 6. In the **Advanced Settings** section, enable **Terminate User Session by ID Token**. > > 7. Click Save. > > 7. On the Resources tab, next to Allowed Scopes, click the pencil icon ([icon: pencil, set=fa]). > > 1. In Scopes, select the following values: > > `email` > > `phone` > > `profile` > > | | | > | - | ------------------------------------------ | > | | The `openid` scope is selected by default. | > > The result resembles the following: > > ![Adding scopes to an application.](../../../_images/pingone-oidc-scopes-en.png)Figure 1. Adding scopes to an application. > > 8. Optionally, on the Policies tab, click the pencil icon ([icon: pencil, set=fa]) to select the authentication policies for the application. > > | | | > | - | -------------------------------------------------------------------------------------------------------------------------------------- | > | | Applications that have no authentication policy assignments use the environment's default authentication policy to authenticate users. | > > If you have a DaVinci license, you can select PingOne policies or DaVinci Flow policies, but not both. If you do not have a DaVinci license, the page only displays PingOne policies. > > To use a *PingOne policy*: > > 1. Click [icon: plus, set=fa]Add policies and then select the policies that you want to apply to the application. > > 2. Click Save. > > PingOne applies the policies in the order in which they appear in the list. PingOne evaluates the first policy in the list first. If the requirements are not met, PingOne moves to the next one. > > For more information, see [Authentication policies for applications](https://docs.pingidentity.com/pingone/applications/p1_auth_policies_for_applications.html). > > To use a *DaVinci Flow policy*: > > 1. You must clear all PingOne policies. Click Deselect all PingOne Policies. > > 2. In the confirmation message, click Continue. > > 3. On the DaVinci Policies tab, select the policies that you want to apply to the application. > > 4. Click Save. > > PingOne applies the first policy in the list. > > 9. Click Save. > > 10. Enable the OAuth 2.0 client application by using the toggle next to its name: > > ![Enable the application using the toggle.](../../../_images/pingone-apps-enable-client-en.png)Figure 2. Enable the application using the toggle. > > The application is now configured to accept client connections from and issue OAuth 2.0 tokens to the JavaScript example PingOne applications and tutorials covered by this documentation. Complete the following tasks to prepare your PingOne Advanced Identity Cloud tenant for PAR: > **Collapse: Task 1. Create a demo user** > > The samples and tutorials in this documentation often require that you have an identity set up so that you can test authentication. > > To create a demo user in PingOne Advanced Identity Cloud, follow these steps: > > 1. Log in to your PingOne Advanced Identity Cloud tenant. > > 2. In the left panel, click Identities > Manage. > > 3. Click [icon: plus, set=fa]New Alpha realm - User. > > 4. Enter the following details: > > * **Username** = `demo` > > * **First Name** = `Demo` > > * **Last Name** = `User` > > * **Email Address** = `demo.user@example.com` > > * **Password** = `Ch4ng3it!` > > 5. Click Save. > **Collapse: Task 2. Register a public OAuth 2.0 client** > > Public clients do not use a client secret to obtain tokens because they are unable to keep them hidden. The Orchestration SDKs commonly use this type of client to obtain tokens, as they cannot guarantee safekeeping of the client credentials in a browser or on a mobile device. > > To register a *public* OAuth 2.0 client application for use with the SDKs in PingOne Advanced Identity Cloud, follow these steps: > > 1. Log in to your PingOne Advanced Identity Cloud tenant. > > 2. In the left panel, click Applications. > > 3. Click [icon: plus, set=fa]Custom Application. > > 4. Select OIDC - OpenId Connect as the sign-in method, and then click Next. > > 5. Select Native / SPA as the application type, and then click Next. > > 6. In Name, enter a name for the application, such as `Public SDK Client`. > > 7. In Owners, select a user that is responsible for maintaining the application, and then click Next. > > | | | > | - | ---------------------------------------------------------------------------------- | > | | When trying out the SDKs, you could select the `demo` user you created previously. | > > 8. In Client ID, enter `sdkPublicClient` > > 9. Select **Configure for SDK Sample Apps**. > > 10. Click Create Application. > > PingOne Advanced Identity Cloud creates the application and displays the details screen. > > 11. On the Sign On tab: > > 1. In Sign-In URLs, ensure the following values appear, or add them if they don't: > > `https://localhost:8443/callback.html` > > | | | > | - | ----------------------------------------------------------- | > | | Also add any other domains where you host SDK applications. | > > 2. In Grant Types, ensure the following values appear: > > `Authorization Code` > > `Refresh Token` > > 3. In Scopes, ensure the following values appear: > > `openid profile email address` > > 12. Click Show advanced settings, and on the Authentication tab, confirm the following properties: > > 1. In Token Endpoint Authentication Method, select `none`. > > 2. In Client Type, select `Public`. > > 3. Enable the Implied Consent property. > > 13. Click Save. > > The application is now configured to accept client connections from and issue OAuth 2.0 tokens to the example applications and tutorials covered by this documentation. > **Collapse: Task 3. Configure the OAuth 2.0 provider** > > The provider specifies the supported OAuth 2.0 configuration options for a realm. > > To configure the PingOne Advanced Identity Cloud OAuth 2.0 provider for use with the Orchestration SDKs and enable PAR: > > 1. In your PingOne Advanced Identity Cloud tenant, navigate to Native Consoles > Access Management. > > 2. In the left panel, click [icon: plug, set=fa]Services. > > 3. In the list of services, click OAuth2 Provider. > > 4. On the Core tab, ensure Issue Refresh Tokens is enabled. > > 5. On the Consent tab, ensure Allow Clients to Skip Consent is enabled. > > 6. On the Advanced tab, enable Pushed Authorization Requests. > > 7. Click Save Changes. Complete the following tasks to prepare your PingAM server for PAR: > **Collapse: Task 1. Create a demo user** > > The samples and tutorials in this documentation often require that you have an identity set up so that you can test authentication. > > To create a demo user in PingAM, follow these steps: > > 1. Log in to the PingAM admin UI as an administrator. > > 2. Navigate to [icon: address-card, set=fa]Identities, and then click [icon: plus, set=fa]Add Identity. > > 3. Enter the following details: > > * **User ID** = `demo` > > * **Password** = `Ch4ng3it!` > > * **Email Address** = `demo.user@example.com` > > 4. Click Create. > **Collapse: Task 2. Register a public OAuth 2.0 client** > > Public clients do not use a client secret to obtain tokens because they are unable to keep them hidden. The Orchestration SDKs commonly use this type of client to obtain tokens, as they cannot guarantee safekeeping of the client credentials in a browser or on a mobile device. > > To register a *public* OAuth 2.0 client application for use with the SDKs in AM, follow these steps: > > 1. Log in to the PingAM admin UI as an administrator. > > 2. Navigate to [icon: list-alt, set=fa]Applications > OAuth 2.0 > Clients, and then click [icon: plus, set=fa]Add Client. > > 3. In Client ID, enter `sdkPublicClient`. > > 4. Leave Client secret empty. > > 5. In Redirection URIs, enter the following values: > > `https://localhost:8443/callback.html` > > | | | > | - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | > | | The Orchestration SDK for JavaScript attempts to load the redirect page to capture the OAuth 2.0 `code` and `state` query parameters that the server appended to the redirect URL.If the page you redirect to does not exist, takes a long time to load, or runs any JavaScript you might get a timeout, delayed authentication, or unexpected errors.To ensure the best user experience, we ***highly recommend*** that you redirect to a static HTML page with minimal HTML and no JavaScript when obtaining OAuth 2.0 tokens. | > > \+ > > | | | > | - | --------------------------------------------------------------------------------------------------------------- | > | | Also add any other domains where you will be hosting SDK applications. . In Scopes, enter the following values: | > > \+ `openid profile email address` . Click Create. > > \+ PingAM creates the new OAuth 2.0 client, and displays the properties for further configuration. . On the Core tab: .. In Client type, select `Public`. .. Disable Allow wildcard ports in redirect URIs. .. Click Save Changes. . On the Advanced tab: .. In Grant Types, enter the following values: > > \+ > > ```none > Authorization Code > Refresh Token > ``` > > 1. In Token Endpoint Authentication Method, select `None`. > > 2. Enable the Implied consent property. > > 1. Click Save Changes. > **Collapse: Task 3. Configure the OAuth 2.0 provider** > > The provider specifies the supported OAuth 2.0 configuration options for a realm. > > To configure the PingAM OAuth 2.0 provider for use with the Orchestration SDKs and enable PAR: > > 1. Log in to the PingAM admin UI as an administrator. > > 2. In the left panel, click [icon: plug, set=fa]Services. > > 3. In the list of services, click OAuth2 Provider. > > 4. On the Core tab, ensure Issue Refresh Tokens is enabled. > > 5. On the Consent tab, ensure Allow Clients to Skip Consent is enabled. > > 6. On the Advanced tab, enable Pushed Authorization Requests. > > 7. Click Save Changes. ## Configuring an OIDC client for PAR in JavaScript To enable PAR, set `par: true` in the `OidcConfig` object passed to the `oidc()` function. When `par: true`, the SDK performs the following steps during each OIDC sign-on: 1. Collects all authorization parameters (client ID, scopes, redirect URI, PKCE challenge, and any additional parameters). 2. Sends them as a `POST` request to the server's `pushed_authorization_request_endpoint`. 3. Receives a short-lived `request_uri` from the server. 4. Redirects the browser to the `/authorize` endpoint using only `client_id` and `request_uri`. No other parameters appear in the URL. The `pushed_authorization_request_endpoint` URL is read automatically from the server's `.well-known/openid-configuration` document when the SDK initializes. Enabling PAR in the OIDC client ```typescript import { oidc } from '@forgerock/oidc-client'; const client = await oidc({ clientId: '6c7eb89a-66e9-ab12-cd34-eeaf795650b2', redirectUri: 'com.example.demo://oauth2redirect', scope: 'openid profile email', par: true, serverConfig: { wellknown: 'https://auth.pingone.ca/3072206d-c6ce-ch15-m0nd-f87e972c7cc3/as/.well-known/openid-configuration', }, }); ``` Obtaining the authorization URL, handling the redirect, and exchanging the code for tokens all work identically to a standard OIDC flow. | | | | - | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | The server must expose a `pushed_authorization_request_endpoint` in its `.well-known/openid-configuration` document.If `par: true` is set but the endpoint is absent from `.well-known`, the SDK returns a `PAR_NOT_CONFIGURED` error rather than falling back to the standard flow\.If `par: false` is set explicitly and the server's `.well-known` document contains `require_pushed_authorization_requests: true`, the SDK returns a configuration error rather than proceeding.If `par` is omitted and the server's `.well-known` document contains `require_pushed_authorization_requests: true`, the SDK automatically uses PAR without requiring an explicit `par: true` setting.To verify, fetch the `.well-known` document for your server and confirm that `pushed_authorization_request_endpoint` is present before enabling this flag. | ## Implementing PAR with background authorization The Orchestration SDK for JavaScript supports background authorization for token renewal without user interaction. It obtains an authorization code silently using a hidden iframe. PAR works transparently with background authorization. When `par: true`, or when the server requires PAR, the SDK uses the PAR flow to build the slim authorize URL before dispatching the iframe request. The iframe receives the slim URL containing only `client_id` and `request_uri`, so the same security benefit applies as with the standard redirect flow. Using background authorization with PAR ```typescript import { oidc } from '@forgerock/oidc-client'; const client = await oidc({ clientId: '6c7eb89a-66e9-ab12-cd34-eeaf795650b2', redirectUri: 'com.example.demo://oauth2redirect', scope: 'openid profile email', par: true, serverConfig: { wellknown: 'https://auth.pingone.ca/3072206d-c6ce-ch15-m0nd-f87e972c7cc3/as/.well-known/openid-configuration', }, }); if ('error' in client) { console.error(client.error); } else { // Requires an active session on the authorization server const tokens = await client.authorize.background(); } ``` | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | | Background authorization with PAR requires an active session on the authorization server. For example, an existing login session.If no session is present, the authorization server returns a `login_required` error, which the SDK surfaces as an `AuthorizationError`. | ## Adding data to PAR requests When PAR is enabled, the **OIDC** module automatically includes `clientId`, `redirectUri`, `scope`, PKCE parameters, and `state` in the PAR request body. To include extra parameters in the PAR POST body, pass them in a `query` object when calling `authorize.url()` or `authorize.background()`. Adding extra parameters to the PAR request body ```typescript const authorizeUrl = await client.authorize.url({ query: { acr_values: 'urn:acr:example', login_hint: 'user@example.com', }, }); ``` The SDK merges `query` values into the PAR POST body before sending the request to the server, and *does not* append them to the slim `/authorize` redirect URL. ## Learn more * [Pushed Authorization Requests (RFC 9126)](https://datatracker.ietf.org/doc/html/rfc9126) * [PingOne Advanced Identity Cloud PAR documentation](https://docs.pingidentity.com/pingoneaic/am-oauth2/oauth2-authz-grant-par.html) * [PingAM PAR documentation](https://docs.pingidentity.com/pingam/8/oauth2-guide/oauth2-authz-grant-par.html)