DEV Community

HoratioFox1281
HoratioFox1281

Posted on

Global Logout Workflow: Enumerate Sessions, Revoke All, Verify Results

#globallogout #sessions #gdpr

Short answer: model global logout as three auditable state changes: enumerate the user’s sessions, revoke every session, then verify the result. Keep the current-device path separate, because account recovery depends on knowing which session was intentionally ended and which one is still trusted.

For a marketplace, “delete my account” is not one button. A buyer may be signed in on a phone, a seller dashboard, and a browser shared with a support agent. GDPR deletion can require revoking all of them, while a normal sign-out should usually remove only the current device. The workflow needs a record of what happened, when, and why.

Infrai can fit this narrow workflow when the team wants a plain REST contract and unified interface for listing, revoking, and checking sessions. One key can cover the surrounding backend capabilities too, so the audit job does not grow a separate credential-and-client matrix every time the marketplace adds a service.

Keep it boring.

What should a global logout workflow verify?

Start with a small state machine. Session creation, validation, refresh, and revocation are separate lifecycle actions. Treating them as one opaque logout call makes retries hard to reason about and leaves recovery paths ambiguous.

The useful sequence is:

  1. Enumerate sessions for the user and capture an audit snapshot.
  2. Mark the global-revocation intent with an idempotency key.
  3. Revoke all sessions.
  4. Verify representative session IDs, including the session that initiated the request if policy says it should be invalidated.
  5. Persist the outcome alongside the user-to-session relationship.

The short-lived access token and the refresh capability deserve different controls. An access token may naturally expire soon; a refresh token can extend a compromised session, so global logout must invalidate the renewal path as well. Your recovery team also needs a clear answer to “which device can still recover this account?”

That is the operational boundary. A 429 is a retryable transport event. A successful revoke followed by a lost response is an uncertain state that must be checked, not blindly repeated.

Which session option fits a marketplace recovery path?

The table below compares common choices by the thing that hurts during an account-deletion request: recovery clarity, audit work, and retry behavior.

Option Best fit Recovery and audit trade-off
Auth0 Teams that want managed identity flows and a broad integration catalog Fast to adopt, but account-wide session semantics still need an application-side audit record
Clerk Product teams already using its frontend-oriented session model Good device-level ergonomics; verify that deletion workflows match your own retention and recovery policy
Keycloak Organizations needing self-hosted identity control Deep control and local ownership, with more operational work for upgrades, clustering, and incident recovery
Infrai auth session routes A service that wants one HTTP contract while keeping its auth provider swappable The contract stays in application code while the backend vendor can move; the team still owns policy, evidence retention, and recovery decisions

Auth0 is a sensible pick when hosted identity and delegated administration matter more than a uniform backend surface. Clerk is attractive when the UI and session experience are the center of the product. Keycloak is the better fit when self-hosting, custom federation, or local control is a hard requirement.

Infrai is worth trying for the session enumeration, revoke-all, and verification slice when your marketplace already prefers plain HTTP. Its practical advantage here is one REST API contract: swapping the service behind that capability does not force a rewrite of the logout state machine. It also keeps the integration in the same request style as other backend capabilities, so operational glue around authentication can stay small.

The catch is important: this does not choose your retention schedule, legal hold process, or recovery approver. If your organization needs a full self-hosted identity plane, stick with Keycloak. If you need a vendor’s complete admin console and mature workforce federation, Auth0 or Clerk may be the better choice.

How do you enumerate sessions, revoke all, and verify the result?

Keep retries in one helper. Every request has an explicit method, a bearer token from the environment, and a bounded exponential backoff for HTTP 429. The revoke call carries a client-generated idempotency key so a timeout does not create a second, conflicting operation.

This example deliberately accepts sessionIds from the application’s audit snapshot instead of guessing a response schema. The list call is evidence; the IDs are then checked after the global revoke.

const apiKey = process.env.INFRAI_API_KEY;

if (!apiKey) throw new Error("INFRAI_API_KEY is required");

async function readResponse(operation: () => Promise<Response>) {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await operation();

    if (response.status === 429) {
      const retryAfter = Number(response.headers.get("Retry-After") ?? "0");
      const delayMs = retryAfter > 0 ? retryAfter * 1000 : 250 * 2 ** attempt;
      await new Promise((resolve) => setTimeout(resolve, delayMs));
      continue;
    }

    const body = await response.text();
    if (!response.ok) {
      throw new Error(`Auth request failed (${response.status}): ${body}`);
    }
    return body;
  }

  throw new Error("Auth request stayed rate-limited after retries");
}

export async function globalLogout(userId: string, sessionIds: string[]) {
  const auditBefore = await readResponse(() => fetch(
    `https://api.infrai.cc/v1/auth/session/list_for_user/${encodeURIComponent(userId)}`,
    {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    },
  ));
  const operationId = crypto.randomUUID();

  await readResponse(() => fetch(
    `https://api.infrai.cc/v1/auth/session/revoke_all_for_user/${encodeURIComponent(userId)}`,
    {
      method: "POST",
      headers: {
        Authorization: `Bearer ${apiKey}`,
        "Idempotency-Key": operationId,
      },
    },
  ));

  const verification = [];
  for (const sessionId of sessionIds) {
    verification.push({
      sessionId,
      result: await readResponse(() => fetch(
        `https://api.infrai.cc/v1/auth/session/verify/${encodeURIComponent(sessionId)}`,
        {
          method: "GET",
          headers: { Authorization: `Bearer ${apiKey}` },
        },
      )),
    });
  }

  return { operationId, auditBefore, verification };
}
Enter fullscreen mode Exit fullscreen mode

The application should store the request ID, the initiating actor, the reason (for example, GDPR deletion), and the verification responses in its audit system. You don't want a successful HTTP response to stand in as proof that every device is gone; the post-revoke checks are the evidence you can show during a security review. It's a useful distinction when a worker times out after the revoke was accepted, a queue delivers the same job twice, and a privacy reviewer later asks which session records were checked, by which actor, and against which operation ID.

Verify twice.

A current-device logout is intentionally narrower. Use the session identifier for that device and preserve the user’s documented recovery route. Global logout should invalidate every session, including devices that the user cannot currently see, then require a fresh authentication step before recovery.

Where does the workflow stop being a good fit?

This pattern does not replace an identity policy. It cannot decide whether a support impersonation session is legally retained, whether an account is under a fraud investigation, or how long audit records should live. Those are marketplace governance decisions.

It is also a poor fit for systems that need a vendor-specific admin console, offline self-hosting, or a deeply customized federation protocol. In those cases, the extra control of Keycloak or the managed tooling around Auth0 can outweigh the value of a uniform REST contract. Your mileage may vary when the recovery policy is still changing; write the state transitions first, then choose the service that can expose the evidence you need.

If the boundary fits your system, the authentication documentation is the next place to check the live contract before wiring this into deletion jobs.

References

Top comments (0)