Technical clarification required: strict token revocation during coordinator failover

Getting Started
1

Hello LiveKit Support Team,

We are developing platform using LiveKit Cloud for realtime audio/video transport, with PostgreSQL as the authoritative source of state.

We are implementing high-availability coordinator recovery and need a supported way to retire all credentials belonging to an old coordinator generation before admitting participants under a new generation.

Our investigation identified an ambiguity between LiveKit’s Cloud documentation and public protocol definition concerning RemoveParticipant, revoke_token_ts, default cutoff behavior and refreshed access tokens.

Could your engineering team clarify the following?

  1. Is there a supported server-authoritative operation that strictly revokes all original and automatically refreshed tokens for a participant or room, without requiring the client to estimate LiveKit Cloud’s current time?

  2. What exact cutoff does RemoveParticipant apply when revoke_token_ts is omitted? Is it server time, server time plus 60 seconds, or another value?

  3. What comparison is used against token nbf values, including equality and Unix-second precision?

  4. Can an older or delayed RemoveParticipant request with a lower cutoff reduce or undo the revocation established by a newer request?

  5. Does successful API acknowledgment guarantee that affected tokens can no longer reconnect, including refreshed tokens and tokens already issued but not yet used?

  6. Are there propagation delays, room-server transitions or other conditions that prevent immediate global enforcement?

  7. Is there a supported way to revoke an entire old-generation room’s access credentials and confirm completion before admitting participants into a replacement room?

  8. If strict retirement cannot be guaranteed through the current API, what approach does LiveKit recommend for security-sensitive coordinator failover?

Our intended design uses separate rooms for coordinator generations, database-backed ownership fencing and fail-closed media admission during uncertain handover.

We would appreciate explicit confirmation of the supported guarantees and any limitations, ideally with references to the relevant Cloud implementation or authoritative API contract.

We are not requesting credentials or access to customer data.

Thank you.

2

Hi,

Our investigation identified an ambiguity between LiveKit’s Cloud documentation and public protocol definition concerning RemoveParticipant, revoke_token_ts, default cutoff behavior and refreshed access tokens.

What is the ambiguity exactly?

The authoritative source for information on token revocation is here:

To achieve your use case, you should call RemoveParticipant and pass a revoke_token_ts.

There is a related thread where the request took some short amount of time (ms) to process across nodes:

3

Thanks, Darryn. That’s helpful, and we’ve reviewed the token-revocation documentation you linked.

To clarify the ambiguity:

The Cloud documentation describes the default revocation cutoff as server time with a one-minute buffer, noting that recently refreshed tokens may remain usable. However, the public RoomParticipantIdentity protobuf comment describes the omitted cutoff as now(server)+leeway(1min).

Our concern is specifically about strict revocation during an unexpected backend coordinator failover, where the old coordinator may have already issued or refreshed tokens and may have in-flight management requests.

We understand the recommendation to pass an explicit revoke_token_ts. Could you clarify three remaining points?

  1. Cutoff selection: Is there a supported way to obtain or establish a LiveKit-server-authoritative cutoff that guarantees rejection of all tokens issued or refreshed before retirement, without relying on an unverified application-to-Cloud clock offset or leaving a same-second boundary gap?

  2. Ordering: If two RemoveParticipant requests arrive out of order with different revoke_token_ts values, is the effective revocation cutoff monotonic (the maximum applied), or could a delayed lower-cutoff request weaken an earlier revocation?

  3. Completion: Does a successful RemoveParticipant response guarantee that revocation has propagated sufficiently to deny reconnection across LiveKit Cloud nodes, including with refreshed tokens? If not, what confirmation or bounded propagation behavior should clients rely on?

We already isolate coordinator generations into separate rooms and suspend new media admission during uncertain handover. We’re trying to determine the precise condition under which it is safe to reopen admission.

We would appreciate clarification of these guarantees or the recommended failover pattern. Thanks again.

4

Ah, it took me a while to understand. I checked the code and the docs are correct. Use of the term ‘+leeway(1m)’ is confusing since tokens are rejected if their nfb is 60 seconds before the RemoveParticipant call, not +.

No, there’s no way to guarantee that our clocks are synced, the best thing I can suggest is to set the revoke_token_ts to 30s in advance of when you call RemoveParticipant (the server allows this value to be up to 60 seconds different from its own clock.

A later call for the same room and identity replaces the earlier cutoff, but you mentioned that your coordinators were scoped to the room, so I wouldn’t expect the newer generator to be removing participants from the older room.

No, there are no guarantees but this case will be covered by my response to point 1, which allowed an overlap.

5

Hi Darryn, Thank you so much for your prompt response. I will implement further actions with the points you raised in full consideration. Hopefully, the issues will be fully resolved

Thank you once again for your response.

6

Hi Darryn,

Thank you again for your earlier responses. Your clarifications have been very helpful in understanding the guarantees and limitations of RemoveParticipant and revoke_token_ts.

Following your guidance, we have completed a further technical assessment of our coordinator-failover design and narrowed the remaining concern to room-level containment.

Our architecture uses PostgreSQL-backed coordinator ownership and assigns a separate LiveKit room to each coordinator generation. When coordinator ownership changes, the replacement coordinator operates in a new room, while the previous room must be retired.

We understand that DeleteRoom forcibly disconnects existing participants. However, we also understand that LiveKit can automatically create rooms when participants connect.

We would appreciate clarification on the following:

1. Permanent room retirement

Does LiveKit Cloud provide a supported mechanism to permanently prevent participants from reconnecting to a retired room name, including attempts using previously issued or automatically refreshed access tokens?

In particular, could a participant with an otherwise valid old token recreate or rejoin a room after DeleteRoom has been called?

2. Termination of existing media

Does a successful DeleteRoom response guarantee that all existing audio/video transport and participant connections associated with that room have been terminated across LiveKit Cloud nodes?

If not, is there a documented propagation bound or another way to confirm completion?

3. Recommended containment approach

If permanent room retirement and confirmed termination cannot be guaranteed through DeleteRoom, is there another supported LiveKit Cloud mechanism or recommended architectural pattern for ensuring that a retired coordinator generation can no longer serve media?

Our objective is to prevent an old coordinator generation from continuing media activity after authoritative ownership has transferred, without relying solely on application-clock estimates or best-effort token revocation.

We would appreciate clarification of the supported guarantees and any limitations.

Thank you again for your assistance.