MOQT supports authorization via mutual TLS (mTLS) for endpoint identification and via token-based schemes for fine-grained, application-defined access control. The two mechanisms can be used together.
13.3.1. Mutual TLS
In mutual TLS, both peers present an X.509 certificate during the TLS 1.3 handshake ([RFC8446]), carried in the underlying transport. An endpoint that verifies a server certificate does so following [RFC9525]. An application that authenticates clients via mTLS defines how a client certificate maps to identity.
Once a peer is authenticated, an application MAY use attributes in the peer's certificate as an input to authorization decisions; the granularity and policy of such authorization is out of scope for this document. ### Authorization Tokens {#sec-tokens}
MOQT has functionality to carry Authorization tokens as message parameters. These tokens can vary based on the application requirements. Two variants of authorization tokens have already been defined for MOQT, and more are expected in the future. The current tokens are Privacy Pass Authentication for Media over QUIC [PPA] and Authentication scheme for MOQT using Common Access Tokens [CAT].
Tokens are expected to contain information about which actions and which resources the endpoint providing the token is authorized to perform and access. Relays will verify the token to ensure that the request is authorized.
13.3.2. Replay Attacks
Replay protection for authorization tokens is the responsibility of the specific token scheme used. Token schemes such as [CAT] and [PPA] include requirements for relays when processing tokens and requests.
13.3.3. Preventing Impersonation
A relay MUST ensure that a client cannot publish to namespaces or tracks belonging to another identity. Impersonation occurs when a client publishes objects that appear to originate from a different publisher — for example, by targeting a namespace containing another user's identifier.
To prevent impersonation, a relay MUST verify that the authenticated identity or token scope permits publishing to the specific namespace. The mapping from authenticated identity to permitted namespaces is determined by the authorization framework in use.
When using bearer token-based authentication (e.g., [CAT]), a token that is bound to a client-held key via a confirmation claim prevents a stolen token from being replayed by a different party.
When unlinkable access is used (e.g., [PPA]), the token's scope extensions determine which namespaces the bearer can publish to. Impersonation is still prevented because the token does not grant access beyond its defined scope.
A relay that does not enforce these checks allows any connected client to inject content into arbitrary namespaces, breaking the integrity of content delivery.