Continuous Re-Authentication

Overview

Continuous Re-Authentication is the ongoing authentication layer for users who have already been verified. It applies conditional access based on a real-time evaluation of multiple risk dimensions: who the user is and their role, what device they're using and whether it's recognized, the risk signals from their current session, their behavioral patterns, and the sensitivity of what they're trying to access. These factors combine to determine the appropriate response — no challenge for low-risk sessions, a stepped-up MFA challenge where warranted, full identity re-verification for higher-risk access attempts, or a hard block for sessions that exceed acceptable thresholds.

The result is authentication that matches the actual risk of each situation. Trusted users move through without friction. Higher-risk situations receive a proportional challenge. No one-size-fits-all challenge applied to everyone.

This is the Verified → Trusted transition in the Trust Progression Model.

Level of Assurance

Variable — None (trusted sessions) to High (full re-verification path).

User Friction Level

None for trusted users. Low for SMS Link. Medium for the re-verification path.

End User Requirements

Trusted sessions: none. SMS Link: mobile phone, ability to receive SMS. Re-verification: same as Identity Verification.

Supported Countries

Session risk assessment: global. SMS Link: broad international coverage. Re-verification: US, UK, CA (phone path); 180+ countries (document path).

Use Cases & Fraud Prevention

• Risk-based re-authentication at login — no friction for trusted sessions, targeted challenges where risk warrants it.
• Account recovery — password reset, locked account, MFA re-enrollment.
• MFA registration — step up a user before they register a new second factor.
• Call center authentication — verify caller identity before granting account access.
• Prevents: account takeover, credential stuffing, stolen credential use, bot farms, call center impersonation.

How It Works

flowchart LR
    Start([User session]) --> SR[Session Risk<br/>Passive assessment]
    SR -->|Trusted device + low risk| Approve([Approve — no challenge])
    SR -->|High risk| Deny([Denied])
    SR -->|Device trust missing| FT[SMS Link<br/>Device possession check]
    SR -->|No device trust + medium risk| PII[PII Validation<br/>Identity re-verification]
    FT -->|Confirmed on mobile| Approve
    FT -->|Not confirmed| Deny
    PII -->|Match| Bio[Government ID and Selfie Match<br/>Document + selfie]
    PII -->|No match| Deny
    Bio -->|Pass| Approve
    Bio -->|Fail| Deny

Session Risk: Device fingerprint, IP reputation, velocity, and behavioral signals are assessed silently. The outcome determines the path — no user interaction is required for this step.

Trusted device + low risk → Approve: Device fingerprint matches a registered device for this credential, session risk is clean. No challenge is presented.

High risk → Deny: Sessions flagged for TOR, OFAC match, velocity violation, or flagged IP are denied immediately. No challenge is presented.

Device trust missing → SMS Link: The device is not recognized, but session signals are otherwise clean. A one-time SMS link is sent to the user's registered phone. Must be tapped on mobile — desktop opens or timeouts result in denial.

No device trust + medium session risk → Re-Verification: Unrecognized device combined with elevated session risk signals. The user must complete full identity re-verification: PII Validation (phone-based identity match) followed by Government ID and Selfie Match (document + selfie) if PII cannot be corroborated. This path does not include a separate Session Risk step — risk was already assessed at the start.

Risk Routing Reference

Configuration Options

Template Variations

• Session Risk → approve / SMS Link / re-verification / deny (default)
• Risk thresholds defining each routing tier are configured per-deployment in Policy Manager

Optional Add-ons

• Trust Device — register the device on SMS Link approval; future sessions from that device skip SMS Link
• SIM Swap detection on the SMS Link step
• Email Risk on the Session Risk step

Integration: Gateway (OIDC)

Standard OIDC flow. See Gateway (OIDC) Integration. Your application sends one /authorize request; the hosted UI handles all path routing. The token response reflects which path ran.

Step-by-step Setup

• Navigate to the Workflow page in the Admin Console.
• Click Add Workflow, select Continuous Re-Authentication, name it, and deploy.
• Configure risk thresholds in Policy Manager — which signals route to SMS Link, re-verification, or deny.
• Configure asyncUIRedirect — required for the re-verification path (Government ID and Selfie Match capture).
• Enable Trust Device to register devices on approval and reduce friction on future sessions.

Configuration Options — Gateway-specific

📝

Content coming soon.

Integration: ID Dataweb API

Session Risk returns either policyDecision (approve or deny) or an obligation indicating which step-up path applies. The re-verification path chains PII Validation and Government ID and Selfie Match via forwardApiKey — the same sequence as Identity Verification but without a preceding Session Risk call.

sequenceDiagram
    participant App as Your Application
    participant IDW as ID Dataweb API
    participant User as End User

    App->>IDW: POST /slverify (Session Risk key)
    IDW-->>App: policyDecision or obligation + forwardApiKey

    alt Trusted session
        Note over IDW,App: policyDecision = approve
    else SMS Link
        App->>IDW: GET /async-ui/send-link (SMS Link key)
        IDW->>User: SMS link
        User->>IDW: Taps link on mobile
        App->>IDW: POST /slverify (SMS Link result)
        IDW-->>App: policyDecision (approve / deny)
    else Re-verification
        App->>IDW: POST /slverify (PII Validation key + prefilled data)
        IDW-->>App: forwardApiKey (SMS Link or Government ID and Selfie Match)
        Note over App,IDW: Continues as Identity Verification flow
    else High risk
        Note over IDW,App: policyDecision = deny
    end

Step-by-step Setup

• Check policyDecision on the Session Risk response. If approve or deny, handle directly.
• If obligation returned, check forwardApiKey and the obligation type to determine which path to route.
• For the re-verification path, follow the same API sequence as Identity Verification from the PII Validation step onward.

See SMS Link, PII Validation, and Government ID and Selfie Match for code samples.

Configuration Options — API-specific

📝

Content coming soon.

Testing in Preproduction

Related Resources

→ Trust Progression Model | → Identity Verification | → Identity Binding | → SMS Link | → PII Validation | → Government ID and Selfie Match | → Gateway (OIDC) Integration