Login Authentication

Overview

Login Authentication is a lightweight, risk-adaptive check applied at sign-in. There's no PII Validation and no biometric step — just a device/credential risk check that either lets the user straight through or steps them up to MFA.

It can run two ways: as an OIDC redirect to ID Dataweb's hosted gateway (same pattern as an External MFA), or embedded directly on the login page via the ThreatMetrix JS tag, with the risk decision returned to your app over the API. Either way, the logic is the same: known device + known credential → approve, redirect straight back. Unrecognized device or elevated risk → step up to MFA.

This is a login-time check, not a transaction-time one — it's a low-friction action meant to sit on the sign-in page itself.

Level of Assurance

Low (trusted device, no challenge) to Medium (MFA step-up).

User Friction Level

None for trusted devices. Low for the MFA step-up (SMS Link tap).

End User Requirements

Trusted path: none. Step-up path: mobile phone, ability to receive an SMS link.

Supported Countries

Device/session risk assessment: global. SMS Link step-up: broad international coverage.

Use Cases & Fraud Prevention

• Embedded login risk check — low friction, sits on the customer's own login screen.
• Cheap, standalone step ahead of a fuller auth stack — doesn't require PII or document verification to add value.
• Prevents: credential stuffing, bot/farm login attempts, session/device spoofing at sign-in.

How It Works

flowchart LR
    Start([User signs in]) --> SR[Session Risk<br/>Device + credential check]
    SR -->|Known device + known credential| Approve([Approve — return to portal])
    SR -->|Unknown device or elevated risk| FT[SMS Link<br/>MFA step-up]
    FT -->|Confirmed on mobile| Approve
    FT -->|Not confirmed| Deny([Denied])

Session Risk: Device fingerprint and credential match are checked — silently, no user interaction — either via the OIDC redirect to the hosted gateway, or via the ThreatMetrix JS tag running directly on the login page.

Known device + known credential → Approve: The device is recognized and tied to a trusted credential. User is redirected straight back to the portal (or, on the embedded path, the app gets an approve decision immediately). No challenge.

Unknown device or elevated risk → SMS Link: Device isn't recognized, or risk signals are elevated. A one-time SMS link is sent for the user to confirm on mobile. Confirmed → approve. Not confirmed → deny.

That's the whole flow — no PII Validation, no Government ID and Selfie Match step in this workflow.

Risk Routing Reference

Configuration Options

Template Variations

• Session Risk → approve / SMS Link step-up (default)
• Risk thresholds are configured per-deployment in Policy Manager

Optional Add-ons

• Trust Device — On MFA step-up, offer to trust the device so the next sign-in from it skips step-up. /untrustdevice needs no asi and can be called standalone.
• SIM Swap detection on the SMS Link step

Integration: Gateway (OIDC)

Standard OIDC redirect, same shape as External MFA. See Gateway (OIDC) Integration. Your application sends one /authorize request; the hosted UI runs the device/credential check and either redirects straight back (approve) or runs the SMS Link step-up first.

Step-by-step Setup

• Navigate to the Workflow page in the Admin Console.
• Click Add Workflow, select Login Authentication, name it, and deploy.
• Configure risk thresholds in Policy Manager — what counts as a known device/credential vs. what triggers step-up.

Integration: ID Dataweb API (embedded)

The ThreatMetrix JS tag runs on your own login page; your app calls the Verify API directly rather than redirecting. This is the path that produces a real asi, which is what makes real device trust possible on this workflow.

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 (approve / deny) or obligation

    alt Trusted device + credential
        Note over IDW,App: policyDecision = approve
    else Step-up required
        App->>IDW: GET /doccapture/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)
    end

    opt Trust the device
        App->>IDW: POST /trustdevice (asi from approved run)
    end

Step-by-step Setup

• Check policyDecision on the Session Risk response. If approve or deny, handle directly.
• If obligation returned, call SMS Link and re-submit the result to /slverify.
• On an approved run, optionally call /trustdevice with that run's asi so future sign-ins from the same device skip step-up.
• As always: check the response body, never the HTTP status — a rejected call still returns 200.

See SMS Link for code samples.

Testing in Preproduction

Related Resources

→ Trust Progression Model | → Continuous Re-Authentication | → SMS Link | → Gateway (OIDC) Integration