LiveKit Cloud: verifying revocation for an identity that never joined

Getting Started
1

We are validating token revocation on LiveKit Cloud using the Node server SDK. A room-join token is issued for an identity that has never joined, and RemoveParticipant is called with an explicit revoke_token_ts after token issuance.

In a US build environment, an immediate /rtc/validate request returned HTTP 200, while the signaling WebSocket attempt failed with a generic error. In separate tests from another location, /rtc/validate returned 401 after removal and an authorized control could connect. No token values, project identifiers, or account details are included.

  1. Does explicit revocation guarantee rejection of a token issued to an identity that has never joined the room? Does this apply to initial joins, across all regions and nodes?
  2. What does HTTP 200 from /rtc/validate mean in this situation, and how can we distinguish an authorization rejection from a network or other signaling failure?
  3. Are revocations synchronous or eventually propagated? What is the supported way to verify that a removed identity cannot join immediately, including when the initial token was issued shortly before removal?

We are keeping the security check fail-closed while investigating.

2

Yes, that will be the case. The docs don’t explicitly say that, so I checked the code to confirm.

Technically a 200 with a body success means the server would accept this join right now, but this is not an external, documented API.

There is some propagation delay, but you should have already accounted for that by including revoke_token_ts. There was a similar discussion about this here: Technical clarification required: strict token revocation during coordinator failover