PingOne

Authentication Settings

Use the Authentication Settings page to configure:

  • Logout settings to control how PingOne handles cross-protocol logout and post-logout redirects.

  • Cookie persistence to control whether the browser retains the session token (ST) cookie after it closes.

Configuring logout settings

Use the Logout Settings section to configure how PingOne coordinates logout requests and responses across single sign-on (SSO) protocols and where PingOne redirects the browser after sign-off.

When Cross-protocol logout is enabled, PingOne sends logout requests to the following in the same user session (even when using different protocols) when it receives a supported logout request:

  • OpenID Connect (OIDC) applications

  • WS-Fed applications, including Microsoft 365 applications that use the passive profile through the WS-Fed protocol

  • SAML applications and identity providers (IdPs)

Browsers can always send HTTP GET requests to the /xp/signoff endpoint to trigger cross-protocol logout, regardless of whether the Cross-protocol logout setting is enabled in the PingOne admin console. Learn more in Signoff (Cross-Protocol) in the PingOne API documentation.

Learn more in Cross-protocol logout.

Steps

  1. In the PingOne admin console, go to Authentication > Authentication Settings.

  2. In the Logout Settings section, click the Pencil icon ().

  3. Edit the following settings as needed:

    Setting Description

    Cross-protocol logout

    Controls whether PingOne sends logout requests to applications and IdPs in the same user session across multiple protocols when it receives a supported logout request.

    This setting is disabled by default. Select Enabled for PingOne to coordinate logout when a user signs off. When PingOne receives a supported incoming logout request, it sends an outgoing logout request to applications and IdPs associated with the same session.

    Supported incoming logout requests

    • OIDC relying party (RP)-initiated logout at /as/signoff

    • WS-Fed wa=wsignout1.0 requests at /wsf/prp/<appId>

    • SAML 2.0 single logout (SLO) requests from a SAML application at /saml20/idp/slo

    • SAML 2.0 SLO requests from a SAML IdP at /saml20/sp/slo

    • HTTP GET requests at /saml20/startslo

    Supported outgoing logout requests

    PingOne sends asynchronous OIDC and WS-Fed logout messages first, followed by SAML 2.0 logout messages.

    • OIDC front-channel logout requests to OIDC-based applications

    • WS-Fed wa=wsignoutcleanup1.0 cleanup requests to WS-Federation applications

    • SAML 2.0 SLO to and from SAML applications

    • SAML 2.0 SLO to and from SAML IdPs

    Learn more in Cross-protocol logout.

    Centralized OIDC post logout redirect URI validation method

    Determines whether PingOne validates post_logout_redirect_uri parameter values in OIDC RP-initiated logout requests against the values you added for Centralized post logout redirect URIs. PingOne validates post_logout_redirect_uri parameter values when the request doesn’t include id_token_hint or if the id_token_hint parameter value isn’t a valid ID token.

    When enabled, PingOne uses these redirect URIs instead of the application’s Signoff URLs.

    When Cross-protocol logout is enabled, this setting is automatically enabled and can’t be disabled.

    Centralized post logout redirect URIs

    Specifies the redirect URIs to which PingOne redirects the browser after sign-off. You can enter a maximum of 200 URIs. Supported schemes include https and custom schemes, such as the following examples.

    Supported redirect URI schemes 
    https://app.example.com/signed-out
com.example.app://signed-out
com.example.app://signed-out/logout

    Schemes that use only one slash (/) after the colon aren’t supported. For example, com.example.app:/signed-out.

    PingOne always validates post_logout_redirect_uri values against this list for requests to /xp/signoff and for HTTP GET requests to /saml20/startslo that trigger a SAML 2.0 SLO flow.

    For WS-Fed sign-off requests to /wsf/prp/<appId>, PingOne always validates the wreply value against this list.

    Click Add Redirect URI to add URIs.

  4. Click Save.

Use the Cookie Setting section to configure ST cookie persistence:

Persistent cookie (default)

The browser retains the ST cookie after it closes until the cookie expires or is manually removed.

Non-persistent cookie

The browser discards the ST cookie when it closes. Non-persistent cookies are useful for kiosk or shared workstation use cases when you don’t want the browser to retain the ST cookie after it closes.

Without a persistent ST cookie, the following might not work as intended after the user closes or restarts their browser:

  • Long-lived sessions in PingOne DaVinci flows

  • Authentication policy conditions, such as Last sign-on older than

  • PingID policies that rely on device or recent-authentication context

The ST cookie is also unavailable if the user switches browsers, uses a private or incognito window, or clears cookies.

Before you begin

You must have the Environment Admin role or a custom role with equivalent permissions to view or update SSO cookie settings.

Steps

  1. In the PingOne admin console, go to Authentication > Authentication Settings.

  2. In the Cookie Setting section, click .

  3. For Browser-Persistent Session-Token Cookie, set the desired ST cookie persistence behavior:

    • Enabled (default): PingOne uses a persistent ST cookie to track session information. The browser retains the cookie after it closes until the cookie expires or is manually removed.

    • Disabled: PingOne uses a non-persistent ST cookie. The browser discards the cookie when it closes. When a user closes or restarts their browser, session and other state information is lost.

    When you update this setting, PingOne records an SSO cookie settings updated event in the Audit log. Learn more in Running an audit report.

  4. Click Save.