# LiveKit Cloud: verifying revocation for an identity that never joined

**URL:** <https://community.livekit.io/t/livekit-cloud-verifying-revocation-for-an-identity-that-never-joined/2425>\
**Category:** Getting Started\
**Created:** [November 1, 2026, 7:47pm UTC](https://community.livekit.io/t/livekit-cloud-verifying-revocation-for-an-identity-that-never-joined/2425 "2026-11-01T19:47:31Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Aziz\_alotaibi](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/aziz_alotaibi/32/2977_2.png) [@Aziz\_alotaibi](https://community.livekit.io/u/Aziz_alotaibi)\
**Post date:** [November 1, 2026, 7:47pm UTC](https://community.livekit.io/t/livekit-cloud-verifying-revocation-for-an-identity-that-never-joined/2425/1 "2026-11-01T19:47:31Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![darryncampbell](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/darryncampbell/32/20_2.png) [@darryncampbell](https://community.livekit.io/u/darryncampbell)\
**Post date:** [November 2, 2026, 9:37am UTC](https://community.livekit.io/t/livekit-cloud-verifying-revocation-for-an-identity-that-never-joined/2425/2 "2026-11-02T09:37:47Z")

</div>

> [@Aziz\_alotaibi](#):
>
> 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?

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

> [@Aziz\_alotaibi](#):
>
> 1. 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?

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

> [@Aziz\_alotaibi](#):
>
> 1. 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?

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](https://community.livekit.io/t/technical-clarification-required-strict-token-revocation-during-coordinator-failover/2281)