Vord

Architecture Decision Record

0031. Adaptive authentication: risk signals, device trust, and conditional access

Context

Entra / Okta conditional access — vary the authentication requirement by risk (impossible travel, new device/IP, breached credential, velocity) and device posture (managed / compliant), and detect anomalies (token replay, session anomalies) — is a major competitive and security feature. The threat model flagged risk-based / adaptive auth and token-theft detection as open (§12.8), and device trust as a floating gap. The hard constraint: none of it may compromise edge-statelessness (rule 1).

Decision

  1. A risk-signal pipeline consumes the event stream (ADR-0022): login events, IPs, devices, velocity, and breached-credential hits (proposal 0013) produce a risk score per authentication. It is a consumer of events, not a new hot-path dependency.

  2. Conditional-access policy (per realm, ADR-0012) maps risk + device posture → an auth requirement: allow, step-up (require MFA / a stronger factor via OIDC acr_values, ADR-0020), or deny. The decision is made at issuance (Modgud, ADR-0009) — and "issuance" means every mint, including silent SSO mints from an existing session (ADR-0016): inheriting the session's amr/acr never skips re-running this policy against the current risk score, so a session that was clean at login does not keep minting after its context turns hostile. Requirements are not only factor-shaped: policy can also require accepted terms of use — "the principal has accepted terms version N" is a directory-recorded, evented fact (ADR-0022) checked at issuance like any requirement, re-prompted through the hosted ceremony (proposal 0007) when the realm bumps the version. Same mechanism, no new plane.

  3. The result is encoded in the token (acr/amr, ADR-0015), so enforcement at the edge (Vör) stays stateless (rule 1): the edge reads the achieved assurance from the signed token — never a risk or device lookup on the verification path.

  4. Device trust: devices are registered/bound (passkeys are already device-bound, ADR-0020; managed-device attestation where available); a device is an attribute in the risk decision at issuance, not a hot-path check.

  5. Token-theft detection rides the same signals (replay from a new context, impossible travel) → raise risk → revoke (ADR-0005) or require re-auth. Detection is issuance-side and telemetry-driven (proposal 0012), never on the verification hot path. A mid-session risk spike reaches a live session through the session record's re-evaluation flag (ADR-0016): the risk pipeline sets it, the next mint attempt demands step-up (or the session is terminated outright via the revocation path), and the propagation bound is the session-termination budget (ADR-0039) — region-local session stickiness makes the flag write local, not global.

Consequences

  • Conditional access and risk-based auth without breaking edge-statelessness: the risk and device decision happens at issuance, and the edge enforces it by reading the token's assurance — the same move (ADR-0015) that keeps MFA off the hot path.
  • Resolves the §12.8 risk-based-auth gap and the floating device-trust gap in one model.
  • Detection feeds revocation (ADR-0005) and the security/freshness telemetry (proposal 0012), closing the "detect" leg of the threat model (ADR-0027).
  • The risk engine is a new issuance-side building block consuming the event stream (recorded as architecture for that reason); it is roadmap, not v1, but the constitution- safe shape is fixed now.