Orchestration SDKs

Configuring React Native apps for Pushed Authorization Requests

PingOne PingOne Advanced Identity Cloud PingAM React Native

You can configure React Native apps built with the Orchestration SDK to use Pushed Authorization Requests (PAR, RFC 9126) for OIDC sign-on.

When PAR is enabled, the Orchestration 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.

Enabling PAR is a configuration-only change.

Your app’s authorization flow logic is identical to a standard OIDC sign-on: the Orchestration SDK builds the request, performs the PAR request, and launches the browser internally.

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.

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 SDKs for Android and iOS, 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 ().

    PingOne displays the Add Application panel.

  4. In Application Name, enter a name for the profile, for example sdkNativeClient

  5. Select Native as the Application Type, and then click Save.

  6. On the Configuration tab, click the pencil icon ().

    1. In Grant Type, select the following values:

      Authorization Code

      Refresh Token

    2. In Redirect URIs, enter the following values:

      com.example.demo://oauth2redirect

      org.forgerock.oidc://oauth2redirect

    3. In Token Endpoint Authentication Method, select None.

    4. Click Save.

  7. On the Resources tab, next to Allowed Scopes, click the pencil icon ().

    1. In Scopes, select the following values:

      email

      phone

      profile

      The openid scope is selected by default.

  8. Optionally, on the Policies tab, click the pencil icon () 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 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.

    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.
    Figure 1. Enable the application using the toggle.

The application is now configured to accept client connections from and issue OAuth 2.0 tokens to the Android and iOS PingOne example applications and tutorials covered by this documentation.

Complete the following tasks to prepare your PingOne Advanced Identity Cloud tenant for PAR:

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 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.

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 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:

      com.example.demo://oauth2redirect

      org.forgerock.oidc://oauth2redirect

      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.

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 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:

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 Identities, and then click Add Identity.

  3. Enter the following details:

    • User ID = demo

    • Password = Ch4ng3it!

    • Email Address = demo.user@example.com

  4. Click Create.

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 Applications > OAuth 2.0 > Clients, and then click Add Client.

  3. In Client ID, enter sdkPublicClient.

  4. Leave Client secret empty.

  5. In Redirection URIs, enter the following values:

    com.example.demo://oauth2redirect

    org.forgerock.oidc://oauth2redirect

    Also add any other domains where you will be hosting SDK applications.

  6. In Scopes, enter the following values:

    openid profile email address

  7. Click Create.

    PingAM creates the new OAuth 2.0 client, and displays the properties for further configuration.

  8. On the Core tab:

    1. In Client type, select Public.

    2. Disable Allow wildcard ports in redirect URIs.

    3. Click Save Changes.

  9. On the Advanced tab:

    1. In Grant Types, enter the following values:

      Authorization Code
Refresh Token

    2. In Token Endpoint Authentication Method, select None.

    3. Enable the Implied consent property.

  10. Click Save Changes.

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 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 React Native

To enable PAR, set par: true in the configuration object passed to createOidcClient().

When par: true, the Orchestration 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.

    The pushed_authorization_request_endpoint URL is read automatically from the server’s .well-known/openid-configuration document when the Orchestration SDK initializes.

  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 are required.

    On iOS, additional parameters may appear on this redirect.

    Learn more in Adding data to PAR requests.
Enabling PAR in a PingOne OIDC client
import { createOidcClient } from '@ping-identity/rn-oidc';

const oidcClient = createOidcClient({
    clientId: '6c7eb89a-66e9-ab12-cd34-eeaf795650b2',
    discoveryEndpoint: 'https://auth.pingone.com/3072206d-c6ce-ch15-m0nd-f87e972c7cc3/as/.well-known/openid-configuration',
    redirectUri: 'org.forgerock.oidc://oauth2redirect',
    scopes: ['openid', 'email', 'address', 'profile'],
    par: true,
});

Starting the browser, handling the redirect, and exchanging the code for tokens all work identically to a standard OIDC flow.

The behavior when the server does not publish a PAR endpoint differs between the underlying native platforms.

On iOS, if pushed_authorization_request_endpoint is absent from the .well-known/openid-configuration document, the Orchestration SDK silently falls back to the standard authorization flow, with no error.

Because iOS fails silently, always verify that your server’s .well-known/openid-configuration document contains pushed_authorization_request_endpoint before enabling par: true.

On Android, the Orchestration SDK does not fall back. It attempts the PAR request against an empty endpoint value, which resolves to an unintended destination and the sign-on fails.

Test the behavior on both platforms if your app targets Android and iOS.

Adding data to PAR requests

When PAR is enabled, the OIDC module automatically folds acrValues, additionalParameters, and other optional configuration values into the PAR request body.

Adding parameters to the PAR request body via configuration
const oidcClient = createOidcClient({
    clientId: '6c7eb89a-66e9-ab12-cd34-eeaf795650b2',
    discoveryEndpoint: 'https://auth.pingone.com/3072206d-c6ce-ch15-m0nd-f87e972c7cc3/as/.well-known/openid-configuration',
    redirectUri: 'org.forgerock.oidc://oauth2redirect',
    scopes: ['openid', 'email', 'address', 'profile'],
    acrValues: 'Single_Factor%20Multi_Factor',
    additionalParameters: { custom_param: 'custom_value' },
    par: true,
});

How per-request parameters passed to the authorize() call are handled depends on the underlying native platform:

  • On Android, parameters passed to authorize() are included in the PAR POST body, so they are PAR-protected in the same way as configuration values.

  • On iOS, the Orchestration SDK applies these parameters to the slim /authorize redirect URL after the PAR POST, so they are not PAR-protected.

Adding per-request parameters when calling authorize()
const oidcWebClient = createOidcWebClient(oidcClient);

const result = await oidcWebClient.authorize({
    loginHint: 'user@example.com',
});

Learn more