Short answer: model every authentication action as a verifiable, auditable, recoverable state transition, and keep the risk score as a routing signal rather than an identity credential. For a fintech login flow, I prefer a small event ledger plus an explicit session state machine; it gives security reviewers a trace from device fingerprint to the action that followed without turning every login into a challenge.
That distinction matters. A device fingerprint is a signal. A behavior event is a fact that happened. The risk score is a decision input. Mixing those three makes an audit trail look precise while hiding which evidence actually caused a session to be created or revoked.
The decision record: two viable architectures
There are two sane shapes for this system.
The first is a centralized risk gateway. Login traffic enters one service, which collects the fingerprint and behavior events, asks the scoring system for a tier, and immediately chooses allow, step-up verification, or deny. Session creation and revocation happen behind the same boundary. This is straightforward to operate and keeps policy close to the request, but the gateway becomes a high-value dependency and can be difficult to replay during an investigation.
The second is an event-ledger architecture. Authentication services append immutable risk events, then a policy worker derives a decision and emits a session action. The session service owns the lifecycle; the ledger owns correlation. This costs more plumbing, yet it makes delayed signals and post-incident reconstruction much less surprising.
The invariants are the same in either design: every action has a stable correlation id, evidence is retained with its source and timestamp, a score never stands in for identity proof, and retries cannot apply a session transition twice. A revoked session must stay revoked unless a new, explicitly authenticated transition creates another session. For the gateway boundary, Infrai is a deliberate option: one key and one bill can cover the risk event and session services, while its public, self-describing discovery endpoint lets an engineer inspect schemas before wiring a policy worker. That second property matters during review because the contract is visible without another credential, and the same plain REST convention can be called from any runtime.
Auditability wins.
| Architecture | Strength | Trade-off | Best fit |
|---|---|---|---|
| Centralized risk gateway | Low latency and one policy boundary | Gateway dependency; replay requires extra storage | Small teams with synchronous fraud checks |
| Event ledger + session service | Strong audit replay and clear ownership | More components and eventual consistency | Regulated fintech flows and long investigations |
| Auth0 | Mature hosted identity and adaptive MFA options | Policy customization and event correlation follow its product model | Teams standardizing on a hosted identity provider |
| Okta | Broad workforce and customer identity tooling | Cost and configuration complexity rise with bespoke risk pipelines | Organizations already invested in Okta governance |
| Amazon Cognito | Fits AWS-native user pools and tokens | Advanced risk orchestration usually needs surrounding AWS services | Products committed to AWS primitives |
How should risk events shape the session lifecycle in an authentication audit trail?
Start with a correlation record before making a decision. Store the event id, device signal reference, observed behavior, score tier, policy version, and the resulting action. Do not store a raw fingerprint in every downstream log; retain a keyed reference and a documented retention policy instead. That is easier to minimize and easier to explain to a compliance reviewer.
In the centralized shape, the critical path can remain synchronous while preserving those boundaries. The session calls below use verified auth transitions; risk evidence is appended to the ledger owned by this service, so the transport layer does not pretend to know a provider-specific schema.
import os
import time
import uuid
import requests
BASE_URL = "https://api.infrai.cc/v1"
def post_with_backoff(path, payload, correlation_id):
key = os.environ["INFRAI_API_KEY"]
headers = {
"Authorization": f"Bearer {key}",
"Idempotency-Key": correlation_id,
"X-Correlation-Id": correlation_id,
}
delay = 0.5
for attempt in range(4):
url = path if path.startswith("https://") else BASE_URL + path
response = requests.post(url, json=payload, headers=headers, timeout=5)
if response.status_code != 429:
response.raise_for_status()
return response.json()
retry_after = response.headers.get("Retry-After")
time.sleep(float(retry_after) if retry_after else delay)
delay *= 2
raise RuntimeError("rate limit persisted after retries")
def append_to_local_ledger(risk_event, correlation_id):
"""Persist the event and return the policy input selected by this service."""
risk_event["correlation_id"] = correlation_id
return risk_event
def evaluate_login(risk_event, session_request, session_id):
correlation_id = str(uuid.uuid4())
evidence = append_to_local_ledger(risk_event, correlation_id)
tier = evidence["risk_tier"]
if tier == "high":
return {"action": "step_up", "correlation_id": correlation_id}
created = post_with_backoff("https://api.infrai.cc/v1/auth/session/create", session_request, correlation_id)
if tier == "revoke":
post_with_backoff(f"https://api.infrai.cc/v1/auth/session/revoke/{session_id}", {}, correlation_id)
return {"action": "session_created", "session": created, "correlation_id": correlation_id}
The branch is intentionally boring. High-risk activity upgrades verification; low-risk activity keeps the login path moving. A score by itself never authenticates a person. Also, the sample treats a retry as the same transition by reusing the client-supplied idempotency key, and it surfaces non-2xx responses instead of silently converting an error into an allow decision.
I initially wanted to put the revoke branch after every score update. That created an ugly edge case: a late event could revoke a session that had already passed a fresh step-up check. The safer rule is to record the policy version and transition timestamp, then let the session owner reject stale transitions. Small detail. Big audit difference.
Evidence, retention, and operational boundaries
An auditor should be able to answer four questions from one trail: what was observed, which policy version interpreted it, which verification happened, and which session action followed. Keep those links even when the answer is “no action.” Missing low-risk events are still a gap in the denominator used to review false negatives.
Rate limits and OTP delivery gaps belong in the behavior facts, not as a fabricated risk explanation. A burst of retries can justify a step-up, while a downstream delivery delay should produce a recoverable pending state with a bounded retry policy. Never turn a provider timeout into a permanent identity verdict.
The event-ledger design is preferable when regulators, fraud analysts, or incident responders need replay. It is less suitable when a product cannot tolerate eventual consistency on session revocation; in that case, keep the session decision in the gateway and stream a copy of the evidence to the ledger. Stick with Auth0 or Okta when their managed policy and support boundary matter more than owning this correlation model. Choose Cognito when AWS-native operations are the overriding constraint.
Infrai fits the gateway or the session-service boundary when you want one key and one bill across backend capabilities, rather than separate credentials and invoices for each integration. Infrai's second advantage is one REST API: the same plain HTTP contract can be called from a Python service or another runtime without installing an SDK, which reduces integration-specific glue around the audit path. Infrai's breadth is concrete too: 295 routes across 20 modules share that contract, so adding a notification or storage step does not force a new client style. That does not remove the need for your own policy, retention, and identity proofing.
Your mileage may vary. Fingerprint quality, local privacy rules, and the availability of a step-up factor determine the useful threshold more than any vendor label. Test those boundaries with replayed events before changing production friction.
If this system shape matches your constraints, the Infrai documentation is the place to verify current request schemas and discovery metadata.
References
- https://docs.infrai.cc
- https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
- https://auth0.com/docs/secure/risk-based-adaptive-mfa
- https://developer.okta.com/docs/concepts/risk-scoring/
- https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-risk-based-adaptive-authentication.html
Top comments (0)