All developer docs

PoL Step-up with identity providers (Okta, Auth0, Microsoft Entra)

These are integration patterns, not certified integrations. Each identity provider offers an extension point that can redirect a user to an external check during sign-in and then continue. PoL Step-up fits that model: your extension starts a step-up, the user completes a PoL ceremony, and your extension verifies the result with siteverify before letting sign-in continue.

Common building block: a small PoL bridge web app you host (for example with the Node example in this folder) that:

1. Receives the user from the identity provider with a signed state.
2. Calls POST /v1/stepup/start with action (for example login-high-risk) and an account_hint_hash derived from the user id.
3. Shows a page that runs PoL.execute(sitekey, { action, stepup: client_token }).
4. Verifies the token with siteverify (expected action, account hint hash and, ideally, expected_subject).
5. Returns the user to the identity provider with a signed result.

Auth0

Use a post-login Action with a redirect:

• In the Action, decide when to require PoL (risk signals, new device, admin role).
• Call api.redirect.sendUserTo(BRIDGE_URL, { query: { session_token } }) with a signed token carrying the user id.
• In onContinuePostLogin, validate the token your bridge returns (for example with api.redirect.validateToken) and deny access if the PoL check failed.

Okta

Options depend on your Okta product:

• Inline hooks (for example a registration inline hook) can call your bridge's API to allow or deny an event, which suits PoL Gate on self-service registration.
• For sign-in step-up, use an external identity provider or custom authenticator pattern supported by your Okta edition, with the bridge handling the PoL ceremony. Check Okta's current documentation for the options available on your plan.

Microsoft Entra ID / Entra External ID

• Entra External ID supports custom authentication extensions that call your REST API during sign-up and sign-in events. Use one to require a PoL Gate token at sign-up.
• For workforce step-up, evaluate Entra's external authentication methods (preview at the time of writing) and Conditional Access to trigger the bridge for risky sign-ins.

Binding the person to the account

A step-up token proves a live person completed the check. The verifier also makes sure it is the same person each time:

• The first step-up for an account (identified by your account_hint_hash) binds that account to the person who completed it. Do the first step-up at a trusted moment, for example straight after enrolment or a strong sign-in.
• Later step-ups by anyone else fail with account-mismatch, so a stolen password plus an attacker's own Proof-of-Life does not pass.
• Stronger still: when the user first enrols with PoL Gate, store the pairwise subject from siteverify next to the user record, and pass it as expected_subject on every step-up siteverify. The bridge then refuses a step-up by anyone whose subject differs (subject-mismatch), including on the very first step-up.

Important

• PoL Step-up adds a presence check. It does not replace the identity provider's own authentication, passkeys or security keys.
• In regulated payments (PSD2), position PoL Step-up as an additional anti-fraud layer, not as a strong customer authentication factor, until it is certified for that purpose.
• Re-check each provider's current documentation before building: these extension points change over time.

PoL Recovery

Use the same bridge pattern on your account recovery flow: require a recovery level check (Enterprise plan) before allowing a reset, in addition to your existing recovery controls. Recovery proves a live, present person holding a device-bound key. Because Proof-of-Life keeps no biometric or identity link between devices, it cannot by itself prove that the person on a new device is the original account holder. A recovery completed on a new phone is therefore refused at siteverify (account-mismatch) until your bridge, after its own recovery checks, verifies again with allow_new_device: true; the account is then bound to the new phone's person. Combine it with your existing recovery checks, or require a co-verification vouch from a person already linked to the account.

Proof-of-Life is in early access. Request keys, read the API reference or the privacy notice.