Revoke all my sessions

Outcome

Bump the caller token version, attempt refresh/session revocation and clear Auth cookies; partial store failures require separate verification.

These examples prove local handler behavior with real isolated SQL and explicitly simulated identity/permission dependencies.

Before you start

• Verify the intended authenticated identity and the current credential-scoped action before preparing input. Self and managed-user security operations have different authority; a session id does not authorize a different user.

• Use authorized identity and user/session discovery. Recovery security data and session/device identifiers must remain inside the caller-approved workflow.

• Review the validated plan and intended effect before confirmation. Logout can require reauthentication; recovery verification can send an email. Fixture examples authorize no live mutation or external delivery.

Discover the target

topolo whoami --json
topolo apps --json
topolo actions get app_topolo_auth.me.sessions.revoke_all --detail --json

For user/session actions use the caller subject or a user returned by authorized users discovery, then sessions.list for that exact user. For recovery read me.recovery_email.get before reviewing an approved address. Tenant identity takes no override input.

Input fields

This action accepts exactly {}. Identity and target context come from approved authentication, not additional input fields.

Effects

• Bumps caller token version, attempts revocation of caller refresh/session rows and clears Auth cookies. Core and Session writes are separate; store failures can be hidden behind success.

• Does not revoke API keys or service credentials, and a success does not prove audit persistence.

Interpret the response

Success is HTTP 200 with raw target success/message/data/timestamp. CLI/MCP can wrap or project that response. Record timestamps are epoch seconds; the envelope timestamp is ISO text. These local fixtures simulate token identities, so no response proves live sign-in or browser OAuth recovery.

Logout everywhere acknowledges the affected userId and first bumps the caller token version in Core, then updates caller refresh-token and session rows in the separate Session store and clears Auth cookies. This workflow is not atomic. Store revocation errors are swallowed, so ok true does not prove all stored rows were revoked. Audit errors are nonfatal. API keys and service credentials are separate and unchanged. Verify real protected reads and refresh rejection independently; mocked token fixtures cannot prove JWT invalidation.

Missing access tokens return AUTH_ERROR. A thrown invalid-token error currently becomes SERVER_ERROR in these handlers. Session/recovery/logout prefer an access cookie when present; tenant lookup prefers the Bearer header. Do not combine identities across cookie and Bearer transports or infer an OAuth expiry from every 401/500.

Worked examples

These are complete raw target-handler responses, not CLI/gateway envelopes or live authorization proof. Replace synthetic identifiers using authorized discovery. Save only the reviewed input as payload.json; inspect validation and plan before executing. --confirm assumes the intended operation is approved. Storage and response read-back require separate live token rejection, delivery and recipient verification proof where relevant. Cookies and Bearer tokens must identify the intended principal consistently.

Logout everywhere bumps token version and revokes caller session and refresh rows

Input · payload.json:

{}

CLI:

topolo actions validate app_topolo_auth.me.sessions.revoke_all --data @payload.json --json
topolo actions plan app_topolo_auth.me.sessions.revoke_all --data @payload.json --confirm --json
topolo actions call app_topolo_auth.me.sessions.revoke_all --data @payload.json --confirm --json

MCP call after validation and plan review:

{
  "tool": "topolo_call_action",
  "arguments": {
    "actionId": "app_topolo_auth.me.sessions.revoke_all",
    "input": {},
    "confirm": true
  }
}

Captured local handler response · HTTP 200:

{
  "success": true,
  "message": "Logged out of all devices",
  "data": {
    "ok": true,
    "userId": "usr_self"
  },
  "timestamp": "2026-10-02T00:00:00.000Z"
}

Current revocation stores swallow SQL failures after token-version bump

Input · payload.json:

{}

CLI:

topolo actions validate app_topolo_auth.me.sessions.revoke_all --data @payload.json --json
topolo actions plan app_topolo_auth.me.sessions.revoke_all --data @payload.json --confirm --json
topolo actions call app_topolo_auth.me.sessions.revoke_all --data @payload.json --confirm --json

MCP call after validation and plan review:

{
  "tool": "topolo_call_action",
  "arguments": {
    "actionId": "app_topolo_auth.me.sessions.revoke_all",
    "input": {},
    "confirm": true
  }
}

Captured local handler response · HTTP 200:

{
  "success": true,
  "message": "Logged out of all devices",
  "data": {
    "ok": true,
    "userId": "usr_self"
  },
  "timestamp": "2026-10-02T00:00:00.000Z"
}

Verify the result

• Expect current browser/CLI authentication to require reauthentication. Through a separately authorized identity, inspect caller session status and independently test that old protected requests and refresh tokens are rejected.

• Do not rely solely on ok true or an empty sessions.list after a database fault. Verify affected stores and actual runtime token behavior before claiming all devices were signed out.

Errors and recovery

Anonymous logout everywhere is refused

Captured local refusal · HTTP 401:

{
  "input": {},
  "response": {
    "success": false,
    "error": {
      "message": "Access token required",
      "code": "AUTH_ERROR",
      "details": null,
      "timestamp": "2026-10-02T00:00:00.000Z"
    }
  }
}

Invalid token produces the current logout server error

Captured local refusal · HTTP 500:

{
  "input": {},
  "response": {
    "success": false,
    "error": {
      "message": "Invalid fixture token",
      "code": "SERVER_ERROR",
      "details": null,
      "timestamp": "2026-10-02T00:00:00.000Z"
    }
  }
}

Published recovery guidance

• state_conflict (HTTP 409): Read the current resource state, reconcile the intended change, and retry only if still valid.

• AUTH_ERROR (HTTP 401): Verify the intended identity and access-token transport. Refresh only an expired credential for that same approved context; do not switch organizations automatically.

• SERVER_ERROR (HTTP 500): Inspect the original error and current state. Invalid-token exceptions can return 500. A recovery write or token-version bump may already have happened; do not blindly repeat a mutation or claim a delivery/revocation outcome.

Recovery boundaries

Revoked sessions/refresh tokens have no un-revoke operation here. Reauthenticate through the normal approved flow. After a partial failure preserve evidence and obtain authorized store repair; do not restore old tokens or treat repeated logout as complete repair proof.

Discovery and evidence

This record belongs to app_topolo_auth. Local tests prove real canonical session/recovery email SQL, target-user authorization and handler responses with simulated tokens, identity lookup and Notify results. Verification state is seeded; tokens are unusable. They do not prove live JWT rejection, browser OAuth recovery, email delivery, recipient verification, deployment or production completion.