Relock with Ping

It is a companion to the Relock Integration Guide, which describes the architecture, the relay, and the NGINX/Lua deployment that are the same for every provider. Read that guide first — or alongside this one — and return here for the PingOne specifics.

Replace app.example.com throughout with the domain your application is served from (the domain the Relock relay sits in front of).

Scope: PingOne. This guide targets PingOne (Ping's cloud IdP). PingFederate (self-hosted) follows the same relay and discovery-document approach, but its console and OIDC endpoints differ — pull its endpoints from that server's /.well-known/openid-configuration and adapt the console steps accordingly.

What Relock needs from PingOne. PingOne issues access tokens as signed JWTs by default, and the relay derives its session anchor from the sub (subject) and sid (session ID) claims those tokens carry — resolving to MD5(sub + sid) via the relay's Ping profile. No custom action or claim mapping is required for the two steps below.

Verify once before publishing. Unlike the other three providers, the exact claim set on your PingOne access token depends on your environment's session and scope configuration. Confirm that the access token reaching the ALB contains sid (decode one x-amzn-oidc-accesstoken and check). If sid is absent, Relock falls back to cookie-only verification — still functional, but you lose the token-anchored binding. This is the same one-line check worth running for any provider.

---

Step 1 — Redirect and sign-off URLs

In the PingOne admin console: Applications → Applications → your OIDC Web App → Configuration (click the edit icon).

The sign-off URL is what lets termination cascade through PingOne to the SSO session (see Q2 in the main guide). Without it, a terminated session can silently respawn on the next request. Note the Issuer, Client ID, and Client Secret shown on this tab — you will need them for the ALB.

Step 2 — Scopes

On the application's Access tab (or Resources / Scopes), ensure the openid scope is granted. This is the default for an OIDC application; no additional scopes are required for anchor derivation.

Step 3 — AWS Application Load Balancer

On the HTTPS (443) listener → Rules → Default rule, add an authenticate-oidc action ahead of the forward action (the mechanics are described in §5.2 of the main guide). Populate it with PingOne's OIDC endpoints and the client credentials from Step 1.

Pull the exact endpoint values from PingOne's discovery document — https://auth.pingone.com/<environment-id>/as/.well-known/openid-configuration. The typical pattern:

Do not add an audience extra parameter. PingOne returns a decodable JWT access token by default, which is what the relay reads to derive the anchor. (The audience parameter is required for Auth0 only.)

The ALB now sets its session cookie and injects x-amzn-oidc-accesstoken (plus x-amzn-oidc-data and x-amzn-oidc-identity) into requests reaching the NGINX target.

---

With PingOne and the ALB configured, deploy the relay as described in the Relock Integration Guide → §5.2 The relay. No application code changes are required.