Login Authentication

Risk-adaptive login check — no challenge for known devices and credentials, SMS Link step-up to MFA when the device is unrecognized or risk is elevated. No PII Validation, no biometric step.

Overview

Login Authentication is a lightweight, risk-adaptive check applied at sign-in. There's no PII Validation and no biometric step — just a session risk check that denies high-risk sessions, approves trusted devices with no challenge, and steps everyone else 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:

  • High risk → deny.
  • Low risk + device and credential trusted in the last six months → approve, no challenge.
  • Low risk + device and credential not trusted in the last six months → SMS Link to confirm possession of the user's phone. On confirmation, the user is approved and the device and credential can be trusted for future sign-ins.

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 (SMS Link step-up).

User Friction Level

None for trusted devices. Low for the SMS Link step-up — one tap on a link.

End User Requirements

Trusted path: none. Step-up path: a mobile phone able to receive an SMS link.

Supported Countries

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 and farm login attempts, session and device spoofing at sign-in.

How It Works

flowchart LR
    Start([User signs in]) --> SR[Session Risk<br/>Device + credential check]
    SR -->|High risk| Deny([Denied])
    SR -->|Low risk + trusted<br/>in last 6 months| Approve([Approve — return to portal])
    SR -->|Low risk + not trusted<br/>in last 6 months| SMS[SMS Link<br/>Confirm phone possession]
    SMS -->|Confirmed on mobile| Approve
    SMS -->|Not confirmed| Deny

Session Risk. Device fingerprint, network signals, and credential match are checked silently, with no user interaction — either through the OIDC redirect to the hosted gateway, or through the ThreatMetrix JS tag running directly on the login page. The step has three outcomes:

  • High risk → Deny. The session is denied immediately. The user is not offered a step-up.
  • Low risk, trusted → Approve. The device and credential were trusted within the last six months. The user is redirected straight back to the portal (or, on the embedded path, the app gets an approve decision immediately). No challenge.
  • Low risk, not trusted → SMS Link. The device or credential is new, or its trust is more than six months old. The user steps up to SMS Link.

SMS Link. A one-time link is sent by SMS to the user's phone. Tapping it on the mobile device confirms possession. Confirmed → approve, and the device and credential can be trusted so the next sign-in skips step-up for six months. Not confirmed → deny.

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

Risk Routing Reference

SignalOutcome
High riskDeny
Low risk + device and credential trusted in last 6 monthsApprove — no challenge
Low risk + not trusted in last 6 monthsSMS Link step-up
SMS Link confirmed on mobileApprove — device and credential can be trusted
SMS Link not confirmed / opened on desktopDeny

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 session risk check and either denies, 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 high risk and what counts as a trusted device and credential.

Integration: ID Dataweb API (embedded)

The ThreatMetrix JS tag runs on your own login page, and your app calls the Verify API directly rather than redirecting.

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 / obligation)

    alt Low risk + trusted
        Note over IDW,App: policyDecision = approve
    else High risk
        Note over IDW,App: policyDecision = deny
    else Low risk + not trusted
        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)
        opt Trust the device
            App->>IDW: POST /trustdevice (asi from approved run)
        end
    end

Step-by-step Setup

  • Check policyDecision on the Session Risk response. If approve or deny, handle directly.
  • If obligation is returned, call SMS Link and re-submit the result to /slverify.
  • On an approved SMS Link run, call /trustdevice with that run's asi so sign-ins from the same device skip step-up for the next six months.
  • 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

ScenarioInputExpected Result
Deny — high riskHigh-risk session (e.g. flagged IP, bot signals)deny at Session Risk
Trusted device + credentialDevice and credential trusted within the last six monthsapprove — no challenge
Step-upUnrecognized device or credential, low riskSMS Link obligation → approve after tap
Deny — possessionSMS Link opened on desktopdeny at SMS Link
Device trust round-tripStep up once, trust the device, sign in again from same deviceSecond run: approve with no step-up

Related Resources

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