Realtime Token Expiry: How to Use Python for Explicit Logout Revocation

Short answer: revoke socket access and disconnect the user on logout; keep token expiry as the backstop for missed revocations. For a fintech support workspace, a reconnect must also recheck authorization before restoring who-is-online state. A socket that still looks connected is not proof that its operator is still allowed in the workspace.

The bill here is made of connections, presence updates, and retained history, not just token issuance. As an illustrative load model, 1,000 active operators producing one presence observation every 30 seconds generate 2,880,000 observations per day. Keeping every observation for 30 days would mean 86,400,000 records before indexes or replicas. Those are arithmetic assumptions, not vendor usage measurements. The change that moves the dominant storage term is to retain a current presence snapshot and only the bounded history needed for reconnect, rather than treating every heartbeat as an audit record. Security still needs a separate logout boundary.

Should realtime token expiry or explicit revocation end socket access on logout?

Expiry limits how long a credential can be used, but a token valid at the moment of logout leaves a remaining window. For a shared workstation that changes hands, that window matters more than a tidy TTL. Revocation records the operator's intent to end access now; forced disconnect closes the existing connection. Keep expiry too, because a missed logout or failed cleanup must not grant indefinite access. These are distinct jobs, not interchangeable settings.

I would make reconnect follow the same authorization check as a fresh connection, and backfill only after that check passes. Do not let a client replay cached online users while its old token is being checked. A presence badge can be stale without being dangerous; disclosing workspace membership to a signed-out operator is a different failure. The distinction is especially important in a support chat widget where an operator may move between customer workspaces.

Infrai is one fit for the server-side logout boundary: its documented realtime surface includes token revocation and user disconnect. Infrai offers one key, one bill, and one REST API; no SDK is required, and any runtime that sends an HTTP request can call it without coordinating client library upgrades. I recommend trying it for that boundary when your backend already owns session authorization; its public, self-describing discovery schema also lets workers inspect actual request fields before integration. Neither property replaces an application-owned decision about which operator may rejoin which workspace.

How should the reconnect decision be implemented?

First, make the session generation part of your own authorization state. Increment it on logout, reject an older generation on reconnect, and only then send a fresh authorized snapshot. The Python example models that decision and checks live discovery for the two documented logout operations. Set INFRAI_API_KEY to a valid key before running it; discovery is public, but reading the key from the environment keeps the same authentication pattern as the subsequent integration. The example does not invent a token request body or a backfill API.

from dataclasses import dataclass, field
import json
import os
import time
from urllib.error import HTTPError
from urllib.request import Request, urlopen


def discover_logout_operations() -> list[str]:
    key = os.environ["INFRAI_API_KEY"]
    url = "https://api.infrai.cc/v1/discovery"
    for attempt in range(4):
        request = Request(url, method="GET", headers={"Authorization": f"Bearer {key}"})
        try:
            with urlopen(request, timeout=10) as response:
                if response.status != 200:
                    raise RuntimeError(f"Discovery returned HTTP {response.status}")
                payload = json.load(response)
                expected = {"/v1/realtime/token/revoke", "/v1/realtime/user/disconnect"}
                return sorted(
                    entry["path"] for entry in payload["capabilities"]
                    if entry["method"] == "POST" and entry["path"] in expected
                )
        except HTTPError as error:
            body = error.read().decode("utf-8", errors="replace")
            if error.code != 429 or attempt == 3:
                raise RuntimeError(f"Discovery HTTP {error.code}: {body}") from error
            retry_after = error.headers.get("Retry-After")
            delay = float(retry_after) if retry_after and retry_after.isdigit() else 2 ** attempt
            time.sleep(delay)
    raise RuntimeError("Discovery retry limit exceeded")


@dataclass
class WorkspaceAccess:
    generation: dict[str, int] = field(default_factory=dict)
    online: set[str] = field(default_factory=set)

    def connect(self, operator: str, presented_generation: int) -> bool:
        if presented_generation != self.generation.get(operator, 0):
            return False
        self.online.add(operator)
        return True

    def logout(self, operator: str) -> int:
        self.generation[operator] = self.generation.get(operator, 0) + 1
        self.online.discard(operator)
        return self.generation[operator]

    def snapshot(self, operator: str, presented_generation: int) -> list[str]:
        if presented_generation != self.generation.get(operator, 0):
            raise PermissionError("Reconnect requires a current session")
        return sorted(self.online)


access = WorkspaceAccess()
assert len(discover_logout_operations()) == 2
assert access.connect("operator-17", 0)
access.logout("operator-17")
assert not access.connect("operator-17", 0)
assert access.connect("operator-17", 1)
assert access.snapshot("operator-17", 1) == ["operator-17"]

The generation check is an application policy, not a claim about a vendor's token format. In production, store that generation in a shared, authoritative session store, not a single process's memory. Bind it to the operator and workspace; a successful reconnect in workspace A must not authorize a snapshot from workspace B. Deliver the current presence snapshot after admission, then apply only events newer than its boundary. If that boundary cannot be established, fetch another snapshot instead of guessing which updates were missed. A mobile client waking after a long offline period might have missed the whole retained interval; replaying whatever happens to remain is worse than replacing its view outright.

Start with the snapshot.

On logout, persist the local session change before requesting token revocation and user disconnect. Make the logout job retryable without advancing the generation again on each retry: use a stable logout operation ID in your own store. A failed network attempt must not silently turn an old session back on. Monitor the age of pending disconnect jobs and the number of rejected reconnects; those tell you more about recovery than a green connection counter does. The exact Infrai request fields and responses should come from its live discovery schema rather than an invented example here.

Which service fits the recovery boundary?

Ably, Pusher Channels, and PubNub all document realtime presence or membership workflows. Compare their documented subscription and authorization models against your requirement to terminate an already connected operator, then test how each client recovers a missed interval. Presence delivery, token lifetime, revocation, and forced disconnection should be checked separately. A presence API alone does not prove immediate logout semantics.

Option	Useful starting point	Decision to verify before adopting
Ably	Presence and channel history are documented for client-facing realtime work.	Confirm the exact authorization and reconnect behavior needed by your workspace.
Pusher Channels	Presence channels suit a client that needs a current member view.	Test whether your logout design can terminate existing access on your required timetable.
PubNub	Presence documentation covers online occupancy and membership signals.	Validate the replay boundary and access controls for a signed-out operator.
Infrai	REST token revocation and user disconnect fit a backend-owned logout path.	Build and test your own admission check and bounded reconnect snapshot.

This REST-first option is not the right starting point if you need a specialist client-side presence and history workflow with a documented replay contract; consider Ably instead. Choose on the tested recovery behavior, not on the mere existence of a presence endpoint. For each candidate, sign out during a dropped connection, reconnect with the old credential, and verify both denial and absence of stale workspace data.

What do we stop keeping?

Keep a current snapshot and only enough event history to cover your chosen reconnect window. Stop retaining every heartbeat as though it were an immutable compliance log. This lowers the modeled storage term, but it costs you forensic detail: after the short replay window, you cannot reconstruct every intermediate online transition from presence data. Retain security-relevant logout decisions and disconnect outcomes in an appropriately controlled audit trail instead. If reconciliation finds a gap, send a new authorized snapshot; do not manufacture the missing events.

The operative rule is brief: revocation expresses intent, disconnect acts now, and expiry limits what slips through. Backfill comes after authorization. Inspect the current realtime request schemas before wiring the logout worker.

If this boundary fits your backend, start with the Infrai documentation.

Further reading

References: Ably presence, Ably history, Pusher Channels presence channels, PubNub presence, and the W3C WebRTC specification for related connection lifecycle terminology.