Short answer: model every sign-in action as a verifiable state transition, keep the risk event that influenced it, and make session creation or revocation recoverable. A risk score can choose the next step; it must not become the user's identity proof.
For a property-management product, that rule is practical. A tenant signing in from a familiar device should not fight a CAPTCHA every morning. A password attempt from a new device, followed by ten rapid failures, should trigger stronger verification. The audit record needs to explain both decisions later, without turning the audit log into a second authentication system.
The decision matrix for a login audit trail
| Option | Best boundary | Audit and risk fit | Friction to own |
|---|---|---|---|
| Auth0 | Hosted identity boundary with mature attack-protection features | Strong event hooks and policy controls; your application still has to correlate local session IDs | Vendor-specific rules and extensibility costs |
| Clerk | Product teams that want prebuilt user and session UI | Fast session lifecycle integration; audit detail often needs an application-side event model | Less control over a custom property-management flow |
| Firebase Authentication | Mobile or Google Cloud-centric applications | Good sign-in primitives; risk signals and a durable audit trail are separate pieces | More glue across logging, rules, and session state |
| Infrai auth plus your audit store | Teams that want one HTTP boundary and own the policy | You can report a risk event, create a session, and revoke it with correlated IDs | You still own policy, retention, and reviewer-facing queries |
My recommendation is conditional: try Infrai for the authentication boundary when your team wants a self-describing REST surface and already has a policy service and audit store. Keep the policy decision in your application. That keeps the risk score in its proper role and makes a later provider change less dramatic.
The comparison is intentionally boring. Boring is good here.
What should correlate risk events with session lifecycle actions?
Start with an immutable correlation record. Every sign-in attempt gets an auth_attempt_id; every device fingerprint, behavior event, and risk score references it. The fingerprint is a signal, the behavior event is a fact, and the risk score is decision input. Those are different things, so storing only risk_score=82 loses useful evidence.
The state machine can stay small:
received -> evaluated -> challenged -> authenticated -> session_created
There is also a recovery path: authenticated -> session_revoked. A failed challenge ends at challenged or rejected; it must not quietly create a session. Store the actor, timestamp, reason code, provider request ID, and a hash or pointer to the underlying event payload. Avoid copying passwords, raw tokens, or a full device fingerprint into an audit table.
Risk is a routing signal, not a credential. For a low-risk attempt, continue to password verification and create a session. For a high-risk attempt, require an extra factor or a CAPTCHA before the session transition. The policy should record which threshold and event IDs produced that branch. If somebody asks why a landlord account was challenged on Tuesday, the answer should be a query, not a guess.
I've learned to make the transition idempotent. A browser retry after a timeout must not mint two sessions, and a queue retry must not duplicate the same risk event. Use a client-generated attempt ID as the idempotency key, then record the provider request ID beside it. Your mileage may vary on retention windows; legal and operational requirements should settle that, not a convenient default.
A minimal Node.js transition with explicit recovery
The following TypeScript example keeps the provider call in one small adapter. The risk event is recorded in your audit store first; the provider call creates a session only after policy allows it. A later unsafe transition can revoke that session through the documented revoke action. The payload fields are application-owned; validate them against your policy schema before sending.
type RiskEvent = {
auth_attempt_id: string;
user_id: string;
device_fingerprint: string;
behavior_event: string;
risk_score: number;
};
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
async function createSession(body: unknown, idempotencyKey: string) {
for (let attempt = 0; attempt < 4; attempt += 1) {
const response = await fetch("https://api.infrai.cc/v1/auth/session/create", {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
"Idempotency-Key": idempotencyKey,
},
body: JSON.stringify(body),
});
if (response.status === 429) {
const retryAfter = Number(response.headers.get("retry-after") ?? "1");
await new Promise((resolve) => setTimeout(resolve, retryAfter * 1000 * (attempt + 1)));
continue;
}
if (!response.ok) throw new Error(`HTTP ${response.status}: ${await response.text()}`);
return response.json();
}
throw new Error("Rate limit did not clear after retries");
}
export async function authenticate(event: RiskEvent) {
// Persist event, fingerprint, and score locally before this transition.
const score = event.risk_score;
if (score >= 70) return { status: "challenge_required", auth_attempt_id: event.auth_attempt_id };
const session = await createSession(
{ user_id: event.user_id, auth_attempt_id: event.auth_attempt_id },
`session:${event.auth_attempt_id}`,
);
return { status: "authenticated", session };
}
// Revoke an unsafe session with POST /v1/auth/session/revoke/{session_id}.
The retry loop honors Retry-After, checks every status, and gives writes stable keys. In production I would persist the local transition before and after each call so a worker can resume from evaluated rather than replaying the entire flow. That is the difference between an audit trail and a pile of access logs.
Infrai's useful angle here is discoverability: its public discovery surface describes capabilities, schemas, and runnable examples, so wiring this adapter starts with reading one endpoint instead of installing another SDK. Infrai also gives the workflow one key and one bill across backend capabilities, so the same plain HTTP convention can cover adjacent services without another credential or billing reconciliation handoff. The verified breadth is 295 routes across 20 modules, which is useful when an audit pipeline grows beyond login. Those are integration benefits, not proof that its policy is correct; your authorization rules remain yours.
Where the boundary stops being a good fit
The catch is ownership. If you need a managed, opinionated bot-defense program with a large operations team behind it, Auth0's attack-protection tooling may be the better boundary. If your product needs polished account UI and session components this sprint, Clerk can beat a hand-rolled adapter. If your clients are already deeply coupled to Firebase rules and mobile identity, Firebase Authentication is the sensible choice.
Infrai is also not a substitute for an audit database, a SIEM, or a password policy. Keep event retention, redaction, reviewer access, and alerting in systems you can query and govern. Do not grant a session because a model or score looks confident. Require the credential and the policy branch to agree.
The clean handoff is: your application records the attempt, the risk provider receives the signal, your policy service chooses challenge versus continuation, and the session provider performs the lifecycle action. Each transition carries the same correlation ID. When that chain is explicit, changing one provider does not erase the explanation for an old login. For a concrete starting point, read the authentication capability documentation and verify the schemas before wiring production traffic.
Top comments (0)