Adaptive MFA & Risk Scoring

Traditional MFA is binary: either every login requires a second factor, or none do. This creates a tension between security (always require MFA) and user experience (MFA adds friction). Adaptive MFA resolves this tension by only requiring additional authentication when the login appears risky.

Auris implements adaptive MFA through a risk scoring engine that evaluates each authentication attempt across five dimensions. When the computed risk score exceeds a configurable threshold, Auris escalates the authentication requirements — requesting an additional factor, blocking the attempt, or notifying the user.

How Adaptive MFA Works

The adaptive MFA system operates as a post-authentication step. After the user’s primary credentials are verified (password, magic link, social login), the risk scoring engine evaluates the login context before tokens are issued:

The key insight is that a user logging in from their usual device, usual IP, at their usual time gets through without friction. The same user logging in from a new device in a new country at 3 AM gets an MFA challenge — or is blocked entirely.

The 5-Factor Risk Scoring Model

Each factor contributes a weighted score to the total risk assessment. The individual factor scores are combined into a final score between 0 (no risk) and 100 (maximum risk).

Factor 1: IP Reputation

The engine evaluates the reputation of the source IP address.

IP geolocation is performed using the built-in offline DB-IP City Lite database (no external network calls, EU-compliant by default). ip-api.com and MaxMind GeoIP2 are available as opt-in alternatives via the GEOIP_PROVIDER environment variable. The provider returns metadata including isVpn, isProxy, and isDatacenter flags.

Why it matters: Legitimate users rarely log in from data center IPs or Tor exit nodes. VPN usage is more common and may be expected for some user populations (remote workers, privacy-conscious users), which is why VPN scores are lower than data center or blocklist scores.

Factor 2: Device Trust

The engine compares the current device fingerprint against previously seen fingerprints for this user.

Device fingerprints are computed as a SHA-256 hash of browser characteristics (user agent, screen resolution, timezone, language, installed plugins). The DeviceFingerprint model stores a mapping of userId + fingerprintHash, with a unique constraint preventing duplicates.

Why it matters: A new device is one of the strongest signals that the login may not be from the account owner. Combined with other factors (new IP, new country), a new device significantly increases the risk score.

Factor 3: Geo Anomaly (Impossible Travel)

The engine checks whether the login location is physically plausible given the user’s recent login history.

Impossible travel is detected using the Haversine formula to calculate the great-circle distance between the current and previous login locations, then dividing by the elapsed time to compute the required travel speed:

The default maximum travel speed is 900 km/h (approximate commercial airplane speed). If the required speed exceeds this threshold, the login is flagged as impossible travel.

Why it matters: If a user logged in from Milan 30 minutes ago and is now logging in from Tokyo, the required travel speed would be approximately 18,000 km/h. This is physically impossible, which strongly suggests the second login is from a different person using stolen credentials.

Factor 4: Behavioral Signals

The engine analyzes patterns in the user’s authentication behavior.

Behavioral analysis uses the user’s historical login data (stored in LoginAttempt records) to build a profile of normal behavior. Deviations from this profile increase the risk score.

Why it matters: Credential stuffing attacks and unauthorized access often happen at unusual hours, may be preceded by multiple failed attempts (testing passwords), and may target multiple applications in quick succession.

Factor 5: Action Sensitivity

Different actions carry different inherent risk levels, regardless of the user’s context.

Why it matters: Even if a login context is completely normal (known device, known IP, usual time), changing the account’s email address or disabling MFA should be treated with elevated scrutiny. Action sensitivity ensures that high-impact operations always receive a minimum risk score bump.

Weighted Scoring Formula

The final risk score is computed as a weighted sum of the five factor scores, capped at 100:

Default weights:

Weights can be adjusted in the Console under Settings → Attack Protection → Adaptive MFA to match your threat model. For example:

• A financial application might increase the geo anomaly weight to 2.0
• An application with many VPN users might decrease the IP reputation weight to 0.5
• An application with high admin turnover might increase the action sensitivity weight

Risk Levels

The computed score maps to a risk level:

Risk level thresholds are configurable in the Console. The mapping between risk levels and actions is also configurable:

Step-Up Authentication

Step-up authentication is the process of requiring additional authentication factors when the risk score exceeds a threshold. Auris tracks the “strength” of the current authentication using two standard OIDC claims:

ACR (Authentication Context Class Reference)

ACR is a string indicating the level of assurance of the authentication. Auris uses a tiered ACR model:

AMR (Authentication Methods Reference)

AMR is an array of strings indicating which methods were used during authentication:

Challenge Orchestration

When step-up authentication is required, Auris presents the appropriate MFA challenge based on the user’s enrolled methods and the required ACR level:

Current ACR: basic (password only)
Required ACR: mfa (at least one additional factor)

User has enrolled:
  - TOTP ✓
  - SMS OTP ✓
  - WebAuthn ✗ (not enrolled)

Available challenge methods: TOTP, SMS OTP
Selected challenge: TOTP (highest priority enrolled method)

The challenge selection follows this priority order:

1. WebAuthn (hardware key / passkey) — strongest, phishing-resistant
2. TOTP (authenticator app) — strong, no network dependency
3. SMS OTP — acceptable, but vulnerable to SIM-swapping

If the risk level is CRITICAL and the user has WebAuthn enrolled, Auris may specifically require WebAuthn rather than accepting a weaker factor like SMS.

ACR and AMR in JWT Claims

After authentication is complete (including any step-up challenges), the access token includes the achieved ACR and AMR values:

{
  "sub": "usr_abc123",
  "iss": "https://auth.acme-corp.com",
  "aud": "your-client-id",
  "acr": "urn:auris:acr:mfa",
  "amr": ["pwd", "otp"],
  "exp": 1739880900
}

Resource servers can inspect these claims to enforce their own minimum authentication requirements:

// Require MFA for sensitive API endpoints
const acr = decodedToken.acr
if (acr === 'urn:auris:acr:basic') {
  return Response.json(
    { error: 'This endpoint requires multi-factor authentication' },
    { status: 403 }
  )
}

Custom Risk Rules

In addition to the five built-in factors, Auris supports custom risk rules — administrator-defined conditions that add or subtract from the risk score.

Creating Custom Rules

Custom risk rules are managed in the Console under Settings → Attack Protection → Adaptive MFA → Custom Rules.

Each rule has:

Example Rules

Reduce risk for corporate IPs:

Condition: request.ip IN 203.0.113.0/24
Score Adjustment: -20

Logins from your corporate network are inherently more trusted, so the risk score is reduced.

Increase risk for recently created accounts:

Condition: user.createdAt > NOW - 7 days
Score Adjustment: +15

New accounts are more likely to be created by attackers during a credential stuffing campaign.

Increase risk for specific email domains:

Condition: user.email ENDS_WITH @suspicious-domain.com
Score Adjustment: +25

Temporary email domains or known abusive domains get a risk bump.

Condition Engine

The condition engine supports these operators:

Conditions are evaluated against the same context object available to Actions, so all fields on user, application, connection, request, and tenant are available.

Integration with the Login Flow

Adaptive MFA integrates into the Auris login flow after credential verification:

The risk assessment is stored as a RiskAssessment record in the database with the computed score, the individual factor breakdowns, the risk level, and whether step-up was required. This data is available in audit logs and the attack protection dashboard.

Risk Assessment History

Every risk assessment is stored and accessible in the Console at Settings → Attack Protection → Risk Assessments:

The history view includes charts showing:

• Risk score distribution over time
• Most common risk factors triggering elevated scores
• Step-up MFA success rate (how often users complete the challenge vs abandoning)

This data helps you tune thresholds and weights for your specific user population.

Comparison with Static MFA Policies

Auris supports both models. You can configure mandatory MFA at the tenant level (every login requires a second factor) and adaptive MFA simultaneously. In this configuration, adaptive MFA adds step-up challenges on top of the baseline MFA requirement — for example, requiring WebAuthn instead of TOTP when the risk is high.

Related Concepts

• Multi-Factor Authentication — Configure MFA methods and policies
• Attack Protection — Brute-force, suspicious login, CAPTCHA
• Sessions & Token Rotation — How risk assessments affect session creation
• Security Settings — Console guide for all security controls
• Actions Engine — Custom hooks that run alongside risk scoring