Skip to content

RealtimeKit token windows: plan revocation separately from expiry

What Cloudflare announced

Cloudflare has announced optional not_before and expires_on timestamps for RealtimeKit meeting-participant authentication tokens, alongside individual token revocation. The default lifetime remains 100 days. These are newly announced access controls, according to the 12 November changelog.

Three different lifecycle decisions

The participant documentation specifies RFC 3339 timestamps, a maximum validity of 100 days, and tokens bound to a participant and meeting. Refreshing generates a new token without invalidating the old one. Revoking an individual token leaves other tokens valid. A revoked token can take up to 60 seconds to be rejected everywhere.

Crucially, expiry does not disconnect someone already attending. Reconnection validates the token again and returns HTTP 401 if it has expired. Revocation removes an active participant. Deleting the participant immediately invalidates all their tokens for that meeting and removes them if connected. These distinctions appear in Cloudflare’s RealtimeKit FAQ.

A practical integration checklist

Our recommendation is to define the intended user experience before choosing a lifetime. A scheduled workshop, for example, needs separate decisions about when a guest may join, what happens after a network interruption, and how an organizer withdraws access. Treat those as separate acceptance tests.

  1. Exercise both boundaries. In a test meeting, try joining just before and just after each configured boundary. Record the server time and expected result. Include clients with deliberately incorrect clocks so your interface does not become the authority on access.
  2. Test an interrupted session. Keep one connection open across expiry, then reconnect. Check that the interface explains the next step clearly rather than leaving the guest in an endless retry loop.
  3. Track overlapping credentials. Generate a replacement token, then test the previous token separately. Decide how your backend records issued credentials and which operation an organizer should use to withdraw access.
  4. Measure removal behavior. Observe an active guest while exercising the documented revocation and participant-deletion paths. Record the delay and check what the organizer sees while removal is pending.
  5. Keep test evidence safe. Log operation names, timestamps and outcomes, rather than full bearer tokens. Use disposable meetings and generic test identities, and document how someone regains access after an authorized removal.

This is a proposed test plan, not a report of live service testing. The useful design question is which lifecycle event each control should represent in your application, and whether both guests and organizers can understand the resulting state.

לקריאת הכתבה בעברית

Post a Comment

Previous Post Next Post