Building One Tap for PingFederate 12.3.3: Architecture and Bridge
Learn how to build a local One Tap sign-in implementation for PingFederate 12.3.3 by properly managing distinct states and secure account bridges.
Stock photo for illustration only, not from the actual event
- Modern One Tap sign-in with PingFederate 12.3.3 requires separating web app and authentication states.
- A Secure Account Bridge reads HttpOnly cookies via an origin-restricted iframe using postMessage and nonce.
- Supports OIDC Authorization Code flow with PKCE and silent authentication parameters like prompt=none.
- Part 2 will cover packaging the adapter with Docker and provisioning with Terraform.
Modern sign-in experiences that remember returning users and allow continuation with a single click require more than just a visual account picker when implemented with PingFederate. The browser, PingFederate, and the web application each maintain distinct states, and merging them causes repeated password prompts, stale panels, and broken logout behaviors.
This series details a working local implementation tailored for PingFederate 12.3.3, with the complete source code made available via GitHub at github.com/darkedges/pingfedonetap.
Stock photo for illustration only, not from the actual event
The critical distinction lies in separating the web application's local signed-in state, the PingFederate authentication session determining password challenges, and the Identifier First adapter cookie remembering successful authentications. These distinct states must be carefully coordinated rather than merged together.
Separating session states across different application layers is a foundational security best practice in modern identity federation. By keeping token handling and app-level session management distinct, developers prevent token leakage and maintain granular control over browser storage and application boundaries.
Running the demo application at http://localhost:8080 alongside PingFederate at https://localhost:9031 introduces cross-origin boundaries, meaning the web app cannot inspect cookies directly. The solution introduces a dedicated status-only adapter running on the PingFederate origin to bridge this safely.
"A remembered account is not automatically a passwordless account.": The account chooser answers "who might sign in?" A valid PingFederate authentication session answers "has this user already proved who they are?"
DarkEdges
To ensure secure cross-origin communication, the bridge implements several strict controls:
- Configured origins are normalized, rejecting unexpected paths, query strings, or fragments.
- A randomized nonce ranging from 32 to 128 hexadecimal characters is validated on every message exchange.
- Iframes are sandboxed with allow-scripts and restricted via a narrow Content-Security-Policy frame-ancestors header.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment