Dev.to Security 🔐 Cybersecurity Mon, 26 Oct 2026 04:04:56 +0000 👁 0 📖 6 min read

5 RTC Room Token Facts Explaining Identity and Permissions Clearly

A room token for a video call should answer five questions: who joined, which room they may enter, what they may do, when access ends, and which token instance is being used. It should not carry cursor coordinates, mute state, or other rapidly changing presence data. For an editor embedded beside the call, that separation is the difference between a trustworthy collaborator list and a cursor that appears to belong to the wrong person.

TL;DR: treat the token as a short-lived authorization snapshot, then treat presence as live, server-validated state. Bind every cursor update to the authenticated connection rather than accepting an identity from the message body. Evaluate the result with reconnects and revocations, not only a clean two-user demo.

The tempting first version is one signed blob containing a display name, a room name, and a broad member role. It feels convenient in a notebook. It also mixes durable authorization with mutable UI state, leaving the server to guess what member means after the product gains screen sharing, recording, and collaborative editing.

1. What Identity and Permissions Does an RTC Room Token Carry?

Use a stable, application-scoped subject for authorization. A display name such as Maya is presentation data: it may change, need localization, or collide with another participant's name. The token's subject should instead map to one account, guest, service, or device according to a documented identity policy. JWT defines the sub claim as the subject of the token, while iss identifies the issuer and aud identifies the intended recipient. Those three claims answer different questions. A room service should reject an unexpected issuer or audience even when the signature is valid; a token minted for an analytics service is not automatically valid at the realtime gateway. Guests need the same discipline: give each guest a server-issued opaque subject scoped to the application or session rather than trusting a browser-supplied nickname, store the friendly name separately, and sanitize it before rendering. This keeps user_7f2a tied to one authenticated connection even if three people type Alex.

Names are not authority.

2. Scope room access and actions separately

A token needs an exact room identifier and explicit permissions. Room membership answers where; permissions answer what. Combining them into a string such as editors-admin makes later audits and migrations needlessly ambiguous.

For a call with a shared code editor, useful actions might include publishing audio, receiving media, and updating one's own cursor. A moderator may also remove a participant. Avoid a single admin: true switch when independent capabilities can express the policy more narrowly.

Here is a deliberately generic claim model. It is an application example, not a WebRTC requirement:

{
  "iss": "https://auth.example.test",
  "sub": "user_7f2a",
  "aud": "realtime-gateway",
  "room_id": "review_42",
  "permissions": [
    "media:publish",
    "media:subscribe",
    "cursor:update:self"
  ],
  "iat": 1789948800,
  "exp": 1789949100,
  "jti": "token_01k5"
}

The namespaced permission strings are local policy. Define their semantics in one authorization module, test them there, and keep the rest of the application from interpreting ad hoc variants. If a cursor message claims a different user ID, ignore that field or reject the message; derive the owner from the connection established with sub.

That check is small. It matters.

from dataclasses import dataclass


@dataclass(frozen=True)
class Session:
    subject: str
    room_id: str
    permissions: frozenset[str]


def authorize_cursor_update(session: Session, message: dict) -> dict:
    if "cursor:update:self" not in session.permissions:
        raise PermissionError("cursor updates are not allowed")
    if message.get("room_id") != session.room_id:
        raise PermissionError("room mismatch")

    return {
        "subject": session.subject,
        "room_id": session.room_id,
        "document_id": str(message["document_id"]),
        "line": int(message["line"]),
        "column": int(message["column"]),
    }

The server overwrites identity because authorization came from the token, not from JSON supplied by the client. It should also validate document membership and sensible coordinate bounds before broadcasting the update.

3. Put time limits on authority, not on presence

JWT provides iat, nbf, and exp for issued-at time, not-before time, and expiration. Validate the claims the system uses, allow only a documented amount of clock skew, and keep access tokens short-lived enough for the threat model. There is no universal correct lifetime; reconnect frequency, issuer availability, and the required revocation delay all change the answer.

Expiration alone does not decide what happens to an established media or data connection. That is application policy. One service may let a connection continue until disconnect, while another may reauthorize periodically or close it when the credential expires. Write the choice down and test it, because otherwise two gateways can implement different behavior from the same token.

Bearer tokens deserve special care. RFC 6750 states that any party possessing a bearer token can use it, so protect tokens in storage and transport, never place them in logs, and avoid exposing them in URLs. jti can give an individual JWT a unique identifier, which is useful for replay detection or a denylist, but it does not create revocation by itself.

4. Keep presence out of the credential

Cursor position changes far faster than authorization. Camera state, hand raises, active document, and network quality change too. Encoding any of them in a signed room token produces stale claims and encourages token reissuance for ordinary UI events.

Instead, keep presence ephemeral and connection-bound:

Authenticate the connection and create a server-side session from validated claims.
Accept cursor updates only for the session's subject, room, and allowed document.
Broadcast a monotonically increasing sequence number with the normalized update.
On reconnect, replace the old connection according to a defined device policy and send a fresh presence snapshot.

WebRTC specifies media and data transport behavior, not an application-level room token format. WebRTC data channels can carry arbitrary application data, but using one does not remove the need for authentication, authorization, ordering policy, or input validation. A WebSocket path has the same application concerns. The transport moves bytes; the room service owns the meaning.

This distinction also clarifies presence accuracy. If the server marks a participant offline only after a timeout, the UI will briefly show stale presence during a network partition. If it removes them immediately on a transient disconnect, cursors will flicker. Measure that trade-off under the reconnect behavior your users actually experience.

5. Evaluate the ugly transitions before shipping

A happy-path test with two browser tabs proves very little. The eval harness should perturb the authorization boundary and the connection lifecycle. I would gate the notebook-to-prod transition on a compact matrix like this:

Experiment	Expected invariant	Presence signal
Same display name, different subjects	Updates remain attributable to distinct subjects	No cursor ownership swap
Cursor payload spoofs another subject	Server emits the authenticated subject or rejects the update	No false attribution
Token targets another room	Connection or operation is denied	No cross-room cursor
Permission is absent	Cursor update is denied	Participant may remain visible without edit presence
Token expires during a connection	Documented continuation or disconnect policy occurs	No undefined half-connected state
Network drops and reconnects	Old connection is retired under the device policy	At most one authoritative cursor per session policy

Track incorrect-attribution rate first: cursor updates displayed under the wrong authenticated subject divided by total displayed updates. It should be zero in controlled tests. Then track stale-presence duration, duplicate-cursor duration, denied-operation counts, reconnect completion time, and token-mint failures. Percentiles are more useful than an average for reconnect time because a small slow tail can dominate what people notice.

Add negative tests for altered signatures, wrong audiences, future nbf values, expired credentials, duplicate token identifiers when replay controls are enabled, malformed coordinates, and oversized messages. Do not log the credential to make those tests easier. Log a safe correlation identifier, the decision, the permission checked, and the authenticated subject according to the system's privacy rules.

Token size has an operational cost as well: every extra claim crosses the network on connection establishment and expands what reviewers must understand. Before adding a claim, ask whether the gateway needs it to make an authorization decision. If the answer is no, fetch it from trusted state or keep it in the presence protocol.

The practical rule is stable: credentials establish bounded authority; live state establishes presence. Before copying this design, measure false attribution, stale and duplicate presence during reconnects, authorization denials, and the load created by renewal. Those numbers reveal whether the policy fits a collaborative call far better than a long list of claims.