PingOne

Editing an application - Native

Use the Applications page to edit existing Native applications.

Steps

  1. Go to Applications > Applications and browse or search for the application that you want to edit.

  2. Click the application entry to open the details panel.

  3. On the Overview tab, click the Pencil icon and enter or edit the following:

    Field Description

    Application Name

    A unique identifier for the application.

    Description (optional)

    A brief description of the application.

    Icon (optional)

    A pictorial representation of the application.

    Use a file up to 1MB in JPG, JPEG, GIF, or PNG format.

    Home Page URL

    The default home page for the application.

    Signon URL

    The URL to which the application redirects the end user for sign-on.

    To avoid issues with third-party cookies in some browsers, we recommend that you use a custom domain to give your PingOne environment the same parent domain as your authentication application. Learn more in Domains.

  4. On the Configuration tab, click the Pencil icon and enter or edit the following:

    Field Description

    Client ID

    The unique identifier for the application.

    Client Secret

    The shared secret for the application. Ensure that you protect the client secret and store it in a secure location. To update the client secret, click Generate New Secret. To revoke the previous client secret, click Revoke Previous Client Secret. Learn more in Rotating the client secret for an application.

    Environment ID

    The identifier for the environment that contains the application.

    Response Type

    Select Code, Token, or ID Token for the response type.

    Learn more in Response types.

    Grant Type

    Select Authorization Code, Implicit, Client Credentials, Device Authorization or Refresh Token for the grant type.

    Learn more in Grant types.

    PKCE Enforcement

    Select a value for PKCE code challenge enforcement. This value determines how the application creates the code challenge from the code verifier.

    Learn more in PKCE enforcement.

    PKCE enforcement is available for Authorization Code grant type applications only.

    Device authorization configuration

    Select this option to enable the Device Authorization grant type. You can specify the following:

    Device Path ID (optional)

    Specifies a unique identifier within an environment for a device authorization grant flow to provide a short identifier to the application. The string can contain letters, numbers, hyphens, and underscores and can be up to 50 characters.

    PingOne ignores Device Path ID if Device Custom Verification URI is configured.
    Device Custom Verification URI (optional)

    Specifies an optional custom verification URI. Learn more in Device custom verification URIs.

    Device Authorization Timeout (required)

    The lifetime, in seconds, of the user_code and device_code. The default value is 600 seconds and the maximum value is 3600 seconds.

    Device Polling Interval (required)

    The minimum amount of time, in seconds, that the client should wait between polling requests to the token endpoint. The default value is 5 seconds, and the maximum value is 60 seconds.

    Learn more in Device authorization.

    Refresh Token configuration

    Select this option to enable the Refresh Token grant type. You can specify the following:

    Refresh token duration

    The lifetime of the refresh tokens. If a value is not provided, the default value is 2592000, or 30 days. Valid values are between 60 and 2147483647.

    Refresh token rolling duration

    How long the application can use the refresh token grant type to obtain a new access token and a new refresh token after the most recent user authentication event. If a value is not provided, the refresh token is valid forever. Valid values are between 60 and 2147483647.

    The refresh token rolling duration must be longer than the refresh token duration.
    Refresh token rolling grace period

    The amount of time that a rolled refresh token is still valid in the event that the client failed to receive an updated one during a roll. Valid values are between 0 and 86400 seconds. A value of 0 means that a refresh token becomes invalid after it’s rolled.

    Additional Refresh Token Replay Protection

    Outside of the optional rolling grace period, refresh tokens are intended for one-time use. For increased security, enable this option so that PingOne can invalidate both access and refresh tokens when a refresh token is reused. Learn more in Refresh token rotation.

    The Additional Refresh Token Replay Protection setting is located in the Advanced section.

    Redirect URIs

    The address to which PingOne forwards the OIDC response after authentication.

    The Redirect URI cannot contain a fragment component, such as #somedata. Learn more in Redirection endpoint in the IETF documentation.

    Allow Redirect URI patterns

    Use a wildcard for flexibility in managing redirect URIs. See Redirect URIs.

    Token Endpoint Authentication Method

    Select one of the following:

    • None

    • Client Secret Basic

    • Client Secret Post

    • Client Secret JWT

    • Private Key JWT

    JSON Web Key Set Method

    Select JWKS URL or JWKS. Provide either the URL where PingOne can retrieve the JSON Web Key Set (JWKS) or the web key set itself. You can paste the JSON in one line or multiple lines.

    JWKS Method is required for an application to send asymmetrically signed request objects. To use Private Key JWT for Token Endpoint Authentication Method, PingOne reuses the same JWKS URL or JWKS to process the private key JWT.

    • If Token Endpoint Authentication Method is set to Private Key JWT, you must provide the JWKS Method.

    • If Token Endpoint Authentication Method is set to None, Client Secret Basic, Client Secret Post, or Client Secret JWT, if the JWKS Method is not provided and the application sends an RS256/384/512-signed request object to PingOne, PingOne returns an error.

    Require Pushed Authorization Request

    Require the application to send its authorization requests directly to PingOne, without going through the browser, which can safeguard sensitive information from end-user devices. If Require Pushed Authorization Request is not selected, the application can send plain authorization requests or pushed authorization requests, but pushed authorization requests are not required. Learn more in Pushed authorization requests.

    Pushed Authorization Request Reference Timeout

    Specify how long the pushed authorization request should be valid. The default value is 60 seconds.

    Initiate Login URI

    The application’s login initiation endpoint for third-parties to begin the sign-on process for the application.

    If provided, PingOne redirects users to this URI to initiate SSO to PingOne. The application is responsible for implementing the relevant OIDC flow when the Initiate Login URI is requested.

    Learn more in Initiating Login from a Third Party in the OIDC specification. This URI is required if you want the application to show in the PingOne Application Portal. Learn more in Application portal.

    Target Link URI

    The URI for the application. If provided, PingOne redirects application users to this URI after the user is authenticated. The target_link_uri parameter value in Initiate Single Sign-On URL is also updated with the value specified here.

    Signoff URLs

    The URLs to which the browser can be redirected after a logout has been performed.

    If you include a post_logout_redirect_uri query parameter in the /signoff request, with the same value that was set in the application, the browser will redirect the user to the matching URL.

    Request Parameter Signature Requirement

    Specify how the application sends the optional request parameter in its authorization requests.

    Click Compare options for a description of the different settings.

    • Default: Allows the application to send authorization requests with or without the request parameter. If using the request parameter, the application must include a digital signature.

    • Allow unsigned request parameters: Allows the application to send authorization requests with or without the request parameter. If using the request parameter, the application has the option to include a digital signature or not.

    • Require signed request parameters: Requires the application to use the request parameter and include a digital signature of it in its authorization requests.

    Learn more in Request Parameter Signature Requirement.

    CORS Settings

    Specifies the CORS options for the application. Learn more in Cross-origin resource sharing.

    • Allow any CORS-safe origin (default): Allows the application to access resources from a domain that is CORS-safelisted, according to the Fetch specification.

    • Allow specific origins: Allows the application to access resources from a specific domain.

      • Allowed origins: Specifies the allowed origin domains for CORS. You can specify a domain pattern or a valid IPv4 address. If you use a domain pattern, you can specify one wildcard to match incoming requests.

        You cannot use the wildcard on the domain name.

        For example, the following search patterns are valid:

        • https://*.test.com

        • https://www.app*.test.com

        The following patterns are not valid:

        • https://test*.com

        • https://www.app.test*.com

    • Disallow all origins: Don’t allow the application to access resources from a cross-origin domain.

    After you make changes to the CORS Settings, it can take several minutes for the new settings to take effect, due to time-to-live configuration on the resource.

  5. On the Resources tab, click the Pencil icon and select the check boxes to add appropriate OAuth scopes for the application. Click the Selected scopes tab to see the scopes that are currently selected for the application.

    The OAuth scopes determine the resources that the application can access. If you add OIDC scopes here, the application inherits the attributes associated with that scope.

    If the application uses the Refresh Token grant type, add the offline_access scope to enable the application to request a refresh token from PingOne on a per-request basis. For example, when the application needs a refresh token, it includes the offline_access scope in its request, and PingOne includes a refresh token in its token response. However, when the application doesn’t need a refresh token, it doesn’t include the scope in the request, and PingOne therefore doesn’t include a refresh token in its token response. If the offline_access scope is not added to an application that uses the Refresh Token grant type, PingOne always includes a refresh token in its token response, whether the application needs a refresh token or not.

  6. On the Policies tab, click the Pencil icon and select the authentication policies for the application.

    If you have a DaVinci license, you can select PingOne policies or DaVinci Flow policies, but not both. If you don’t have a DaVinci license, you’ll see PingOne policies only.

    To add one or more PingOne authentication policies, click the PingOne Policies tab. If the application was previously configured with one or more DaVinci flow policies, click Deselect all other Policies to remove them from the application and select the PingOne authentication policies you want to apply to the application. PingOne authentication policies are applied in the order in which they appear in the list. Click the Selected PingOne Policies tab, reorder the policies as needed, then click Save.

    To add one or more DaVinci flow policies, click the DaVinci Policies tab. If the application was previously configured with one or more PingOne authentication policies, click Deselect all other Policies to remove them from the application and and select the DaVinci flow policies you want to apply to the application. PingOne applies the first DaVinci flow policy in the list. Click the Selected DaVinci Policies tab, reorder the policies as needed, then click Save.

    For OAuth-based applications, you can specify another policy in the acr_values parameter in the authorization request. The acr_values parameter specifies the sign-on policies that PingOne should use for authentication. You can include any policies assigned to the application. Specify either a single DaVinci policy by flow policy ID or one or more PingOne policies by name, separated by spaces or the encoded space character %20. For example, acr_values=d1210a6b0b2665dbaa5b652221badba2 or acr_values=Single_Factor%20Multi_Factor.

    Learn more in Authentication policies for applications.

  7. On the Attribute mappings tab, click the Pencil icon and select a PingOne user attribute and map it to an attribute in the application that you are adding.

    Learn more in Customizing OIDC attributes for an application.

    1. Enter an application attribute and then select the corresponding PingOne attribute from the list.

    2. Click the Gear icon to use the expression builder to build an attribute mapping.

      Learn more in Using the expression builder.

  8. On the Access tab, click the Pencil icon and enter or edit the following:

    Field Description

    Application portal display

    Determines whether an application icon appears in the application portal even if the user is allowed to access the application in the application portal based on the group membership policy. Learn more in Application access control.

    Admin only access

    Specifies that a user with an administrator role is required to access the application. The user must have one of the following roles:

    • Organization Admin

    • Environment Admin

    • Identity Data Admin

    • Client Application Developer

    Group membership policy

    Select the group membership policy for the application. Learn more in Groups.

  9. On the Mobile tab, click the Pencil icon and allow mobile authentication for the app:

    Option Description

    Android

    Configure the app for Android by providing the package name for Google Play Services, the package name and app ID for Huawei Mobile Services, or both.

    iOS

    Provide the bundle ID as registered in the app store.

    After you have enabled mobile authentication, you can configure any of the following:

    1. Allow push notifications by providing the following information:

      • For Android apps that use Google Play Services, provide the JSON file that represents your Service Account Credentials.

        You can select the Cloud Messaging option and provide the Server Key, however this approach has been deprecated and is included only for backward compatibility.

      • For Android apps that use Huawei Mobile Services, provide the OAuth 2.0 client ID and client secret.

      • For iOS, provide the team ID, authentication token signing key, and key ID (as provided by Apple to your organization).

        After you save the push credentials, you can use the Send Test button to test them. You have to supply the push token issued by Google, Huawei, or Apple.

    2. Turn on device integrity checking to prevent the use of compromised devices for pairing or authentication.

      You can enable device integrity checking separately for Android and iOS. For Android, you must choose between Google Verification and Internal Verification. Using internal verification will not count against your Google API call quota. You must provide the following additional information, depending on the type of verification you selected:

      • Google verification - select the JSON file that represents your Service Account Credentials

      • Internal verification - enter the Decryption Key and Verification Key from your Google Play Services account

        If an application appears in multiple environments, make sure to provide the same verification credentials and specify the same cache duration for the application in each of the environments. If these settings do not match, unexpected behavior can result. In such cases, you will also see an error message in the audit log. You will see a similar message if you provided incorrect credentials.

    3. If your organization is using the PingOne MFA SDK to allow authentication with a QR code in certain flows, in Universal / App Linkenter the link or URI scheme that the application should use for this purpose, depending on which deep-linking mechanism the app developers used.

    4. Use the Passcode Refresh Duration field to specify the amount of time a passcode should be displayed before being replaced with a new passcode.

      • The package name, app ID, bundle ID, and push notification settings cannot be modified after they have been saved for the application.

      • If you do not have the necessary license for making changes on the Mobile tab, a lock icon displays below the tab name. If you click the lock, a message appears explaining how to obtain the required license. If you previously had a valid license and defined mobile authentication settings for the app, they remain visible on the tab, but you cannot modify the settings or add to them.

  10. Click Save.