MSF supports token-based authorization through pluggable authentication schemes.
Both original publishers and end subscribers can independently acquire authorization
tokens and present them to relays. Relays use these tokens to authorize whether
an end subscriber is permitted to setup the connection, as well as to receive content
and/or to send content.
End subscribers discover authorization requirements by parsing the catalog.
For each track of interest, examine the authInfo field. If present, the
track requires authorization and the subscriber must obtain appropriate
credentials for one of the schemes listed in the field.
Original publishers and end subscribers may obtain authorization tokens from
multiple sources, including out-of-band provisioning or as a parameter in
the connection URI. These tokens can be presented either in the connection
setup message (CLIENT_SETUP) or in control messages (SUBSCRIBE, FETCH, PUBLISH,
PUBLISH_NAMESPACE) as described in Section 11.4.3.
Token acquisition is out of scope for this specification. Both original publishers
and end subscribers independently obtain tokens through mechanisms such as:
The token acquisition endpoint and flow depend on the authorization scheme
and deployment configuration. Original publishers and end subscribers MAY
use the same or different authorization services depending on the deployment.
Tokens MAY also be supplied as parameters in the connection URI. When a
connection URI contains token parameters, the subscriber extracts the token
value and includes it in the appropriate MOQT message. For example:
moqt://relay.example.com/moqt#namespace--name&token=eyJhbGciOiJFZERTQSJ9...
URI parameters provide a convenient mechanism for distributing pre-authorized
playback links. The parameter name and format are deployment-specific.
Once tokens are obtained, both original publishers and end subscribers present
them to relays according to the scheme specification. Tokens MAY be presented
in the SETUP message (CLIENT_SETUP or SERVER_SETUP) using the AUTHORIZATION
TOKEN setup parameter, or in individual control messages using the
AUTHORIZATION TOKEN message parameter.
When a token is associated with a track, it MUST be included in ALL control
messages that accept the AUTHORIZATION TOKEN parameter and are associated
with that track. For end subscribers, this includes SUBSCRIBE, SUBSCRIBE_NAMESPACE,
FETCH, and REQUEST_UPDATE messages. For original publishers, this includes
PUBLISH and PUBLISH_NAMESPACE messages. This requirement applies regardless
of whether the token was also provided in SETUP.
When a relay rejects an authorization token, subscribers SHOULD handle the
failure gracefully:
-
If a SUBSCRIBE or FETCH request is rejected due to invalid or expired
authorization, the subscriber MAY attempt to obtain a fresh token and
retry the request.
-
If a token is rejected due to insufficient scope, the subscriber SHOULD NOT retry with the same token.
-
For interactive applications, subscribers MAY prompt users to
re-authenticate when authorization fails.
-
Subscribers SHOULD implement exponential backoff when retrying failed
authorization attempts to avoid overwhelming the relay or token issuer.
The specific error codes and retry semantics are defined by the authorization
scheme specifications. See [PrivacyPassAuth] for Privacy Pass error handling
and [C4M] for CAT error handling.