Environments: Production, and optionally Staging/UAT Purpose: Configure PingFederate as an OpenID Connect (OIDC) Identity Provider for NPI's Auth0 tenant, with Proof Key for Code Exchange (PKCE) enforced on every sign-in to Vantage.

This guide is for organizations whose security policy requires PKCE. If PKCE is not required, use Configuring PingFederate (OIDC) SSO for Vantage or Configuring PingFederate (SAML) SSO for Vantage.

Overview

NPI connects to your PingFederate server through Auth0's OpenID Connect enterprise connection, using the Authorization Code flow. With PKCE, Auth0 creates a one-time secret (the code verifier) for each sign-in and sends only its SHA-256 hash (the code challenge) to PingFederate. When Auth0 exchanges the authorization code for tokens, it must present the original verifier. An intercepted authorization code is therefore useless to anyone else.

PKCE works alongside the client secret, not instead of it: Auth0 still authenticates to your token endpoint as a confidential client.

Auth0 turns PKCE on automatically for OIDC connections and picks the strongest method your discovery document advertises. Your part is to require PKCE on the PingFederate OAuth client, so a request without it is rejected.

Environment Values

Use the Staging/UAT values only if you want to test before going to production. Create a separate OAuth client for each environment.

1. Prerequisites

Before starting, verify:

• You have Administrator access to the PingFederate administrative console.
• The OAuth authorization server is enabled, with an Access Token Manager and an OpenID Connect Policy configured.
• An IdP adapter or authentication policy is mapped to persistent grants, so PingFederate can authenticate users for OAuth requests.
• Your discovery endpoint is reachable from the internet over HTTPS: https://<your-pingfederate-host>/.well-known/openid-configuration.

2. Create the OAuth Client

The steps show Production values; for UAT, use the UAT column of the Environment Values table.

1. Sign in to the PingFederate administrative console.
2. Navigate to Applications → OAuth → Clients and click Add Client.

2.1 General Settings

• Client ID: npi-vantage-auth0-prod. It cannot be changed after you save.
• Name: NPI Vantage (Auth0) - Prod.
• (Optional) Description: "Enterprise SSO client with PKCE, used by Auth0 for the NPI Vantage production environment."

2.2 Client Authentication

1. Select Client Secret.
2. Check Change Secret, then click Generate Secret.
3. Copy the secret now. PingFederate will not display it again after you save.

2.3 Redirection URIs

In Redirection URIs, add each of the following and click Add:

https://auth.npi-digital.com/login/callback
https://npi-prod.us.auth0.com/login/callback

For a Staging/UAT client, add these instead:

https://auth-uat.npi-digital.com/login/callback
https://npi-uat-2026-05-22.us.auth0.com/login/callback

⚠️ These must match exactly. Do not use wildcards.

2.4 Grant Types, Response Types, and PKCE

• Allowed Grant Types: select Authorization Code only.
• Restrict Response Types: check it and select code only. Implicit and hybrid response types bypass PKCE, so leave them off.
• Require Proof Key for Code Exchange (PKCE): ✅ check it. This option appears only after you select Authorization Code. With it on, PingFederate rejects any authorization request that does not include a code challenge.
• Bypass Authorization Approval: check it, so users are not shown a consent screen on each sign-in.

2.5 OpenID Connect Settings

• ID Token Signing Algorithm: RSA using SHA-256 (RS256).
• ID Token Key Management Encryption Algorithm: No Encryption (the default).
• Policy: the OIDC policy you configure in Section 3, or Default if that policy is your default.

Click Save.

3. Configure Scopes and ID Token Claims

NPI's Auth0 connection requests the scopes openid, profile, and email, and Vantage needs the user's email to match their account. Your OIDC policy must release these claims in the ID token.

3.1 Scopes

Go to System → OAuth Settings → Scope Management and confirm profile and email exist as common scopes (openid is built in). Add any that are missing.

3.2 OpenID Connect Policy

1. Go to Applications → OAuth → OpenID Connect Policy Management. Edit your default policy, or click Add Policy to create one for Vantage.
2. Manage Policy: select an Access Token Manager that issues signed JWTs. Check Include User Info in ID Token.
3. Attribute Contract: confirm or add the claims in the table below.
4. Attribute Scopes: map email to the email scope, and given_name, family_name, and name to the profile scope.
5. Contract Fulfillment: map each claim to its source, as in the table. Click Next, then Save.
6. If you created a new policy, select it in the OAuth client's Policy field (Section 2.5).

Use the claim names exactly as shown, all lowercase. The email must match the email the user is invited to Vantage with.

4. Collect Values and Share Details with the Vantage Team

4.1 Issuer, Discovery URL, and PKCE Methods

Your issuer is the PingFederate Base URL shown in System → Server Settings → Federation Info, for example https://sso.yourcompany.com. Open the discovery document in a browser:

https://sso.yourcompany.com/.well-known/openid-configuration

Check two values in it:

• issuer: the value to send NPI.
• code_challenge_methods_supported: should include S256. Auth0 reads this list to choose the PKCE method. If the field is missing or lists only plain, tell NPI, so the connection can be pinned to S256.

4.2 Client Credentials

From the OAuth client you created in Section 2, copy:

• ✅ Client ID
• ✅ Client Secret (copied when you generated it)

Share the client secret securely, through a password manager share or an encrypted channel agreed with your implementation engineer. Do not send it over email.

4.3 Final Deliverables

If you set up UAT too, send one set for each environment and label it.

5. Test the Connection

Once NPI confirms the Auth0 connection is live, test with the user you named in Section 4.3. If you set up UAT, test there first, then repeat in Production.

5.1 Sign-in test

1. Open a private or incognito browser window.
2. Go to the Vantage login URL for the environment (Production: https://www.npi-digital.com; UAT: https://uat.npi-digital.com) and enter the test user's work email.
3. Confirm you are redirected to your PingFederate sign-in page, not the Vantage password prompt.
4. Sign in. You should land in Vantage, signed in as the test user, with no consent screen.

5.2 Confirm PKCE is in use

1. Before step 2 above, open your browser's developer tools and select the Network tab.
2. After you are sent to PingFederate, find the request to /as/authorization.oauth2.
3. Confirm its query string includes code_challenge= and code_challenge_method=S256.

5.3 Confirm PKCE is required (optional)

In a new private window, open this URL with your own host and client ID. It is an authorization request without a code challenge:

https://sso.yourcompany.com/as/authorization.oauth2?client_id=npi-vantage-auth0-prod&response_type=code&scope=openid&redirect_uri=https://auth.npi-digital.com/login/callback

PingFederate should refuse it with an invalid_request error rather than showing the sign-in page. If the sign-in page appears, Require PKCE is not set on the client.

If any step fails, note the time and the error text, and send them to NPI along with your PingFederate server log entry for that sign-in.

6. Common Errors to Avoid

7. Frequently Asked Questions

Do we still need a client secret if PKCE is on? Yes. Auth0 signs in to your token endpoint as a confidential client, so it authenticates with the client secret and proves PKCE. The two protect against different attacks: the secret proves the caller is Auth0, and PKCE proves the caller is the one that started this sign-in.

Can we use Private Key JWT instead of a client secret? Auth0's OpenID Connect connection supports Private Key JWT client authentication, and PingFederate supports it on the OAuth client. Ask your implementation engineer before changing the client authentication method, because NPI must configure its side to match.

Which PKCE method is used? S256. Auth0 defaults to the strongest method your discovery document lists. Do not allow plain only: it offers much weaker protection.

We use Microsoft Entra ID, not PingFederate. Can we use PKCE? Not through Auth0's dedicated Microsoft Entra ID connection, which does not support PKCE. NPI can instead connect Entra ID through an OpenID Connect connection with PKCE pinned to S256. Ask your implementation engineer for the Entra ID with PKCE setup.

8. Quick Checklist

• (Optional) UAT client set up and tested before Production
• Created OAuth client in PingFederate
• Client secret generated and stored securely
• Both redirect URIs configured
• Authorization Code grant only; response type restricted to code
• Require PKCE checked
• S256 confirmed in code_challenge_methods_supported
• OIDC policy releases email, given_name, family_name
• Issuer, client ID, client secret, domains, and test user sent to NPI
• Test sign-in completed and PKCE confirmed in the browser

Need Help?

If you encounter issues or need assistance, contact your Vantage implementation engineer or reach us at support@npi-digital.com.

Sources

• Auth0: Configure PKCE and Claim Mapping for OIDC Connections
• Auth0: Connect to OpenID Connect Identity Provider
• Ping Identity: Setting up an OIDC application in PingFederate
• IETF: RFC 7636: Proof Key for Code Exchange