Edge Token Usage
The purpose of this document is to describe the use of Edge Tokens and how they are used.
Tokens are a representation of what a user holding a token is allowed to do with the system. Each token is signed using a pre-shared secret so that the Phenix Platform knows that a verified Customer token service generated the token.
With the assurance that a verified Customer service created the token, the Phenix Platform can make decisions about what the token holder can do. Examples include subscribing to a Channel with a specific ID or Alias, subscribing to any channel that has a specific tag, or publishing to a specific room.
Phenix Customer - Someone wanting to use the Phenix infrastructure for streaming
Customer token service - Code written and hosted by the Phenix customer
User - An end user wanting to publish or view a stream
Phenix Platform - Infrastructure delivering the content stream
Token - Cryptographically signed text
Other terms as described in the Phenix glossary of terms
There are four types of tokens for publishing and streaming:
|Token Type||Permits||Include in Call to Create|
|authToken||Creation of a session||forAuthenticationOnly()|
|streamToken||Consumption of a stream||forStreamingOnly()|
|publishToken||Creation of a stream||forPublishingOnly()|
|edgeToken (is both an authToken and a streamToken)||Creation of a session and consumption of streams||default / none|
All that is needed for playback or publishing is a token from the EdgeAuth library, and all that is needed to generate that token is the Application ID and Secret, as well as information about Channels or Rooms. You do not need any user information unless you (optionally) want to restrict the token based on user information, e.g., to a particular session ID. See below for details about restricting tokens.
In other words, a token generated with an Application ID and secret, but no further restrictions other than expiration time, does not cause an error in the library. This token would allow authentication, but does NOT allow streaming for any channel. A token with no Channel ID, Room ID, Channel Alias, or Room Alias designated will fail to stream. Stream tokens for subscribing cannot be used for both streaming and authorization without any configurations/constraints set.
Call Flow Diagrams
An example call flow for an authorization using an Edge token (which combines both authToken and streamToken) to join a Room or a Channel is shown below.
An example call flow for a session-based token flow to join a Room or Channel is shown below. The use of this flow is discussed in the following section.
See the discussion below for details on using the AuthToken when initializing the SDK.
The design of tokens depends on business logic needs. Token creators can decide how narrow a token's scope is.
Note that the applicationId for the publishing and subscribing tokens must match. For example, if publishing is using an applicationId of
mycompany.com, the applicationId used when creating tokens for subscribing must also be
User and Stream Constraints
Tokens can optionally be restricted by any combination of the following:
User Session ID (sessionId)
User IP (remoteAddress)
Publishing/Subscribing Stream Information
Origin Stream (originStreamId) - Provide this to create a "view" token; otherwise, a publish token is generated.
Channel ID (channelId)
Channel Alias (channelAlias)
Room ID (roomId)
Room Alias (roomAlias)
All of the above options are set when the token is created by the EdgeAuth TokenBuilder library. The library is currently available for the following platforms:
For example, if authentication tokens are specific to a ChannelAlias, and there are multiple Channel Aliases to which a user needs access, the customer's token service needs to provide a separate Auth token for each ChannelAlias.
To add a constraint for sessionId to the above example of an Auth token restricted by ChannelAlias, access to an event with multiple Channel Aliases will require as many streaming tokens as there are Auth tokens.
If the only restriction is that an authorized user must not be able to share stream links with an unauthorized user, creating an Auth token with no restriction and a stream token with a session id restriction would be sufficient.
To allow a publisher to only provide content for a room or channel, the PCI needs to create a Publish token that contains the Room ID or Channel ID. If a user can provide content to multiple channels or rooms, multiple Publish tokens must be created.
If a user should be allowed to view content in multiple channels or rooms, the streams within those rooms and / or channels can be tagged with a specific tag, then the token can be restricted to only those streams with that tag via the "tag" restriction. If a new stream is created that has that same tag, any users having tokens that include that tag will be able to view it as well.
When you create EdgeAuth access tokens you can associate tags with each of them. This information can be used, for example, to map users to your internal accounting system or to generate billing reports for your customers. These tags will be available for filtering and as an output column in usage reports.
Each token must have an expiration time after which it is no longer valid or a duration in seconds during which the token is valid. While the token is valid a user may subscribe to the stream, but after the token has expired the subscription request will fail. Likewise, a user may publish a stream while a publishing token is valid, but cannot begin publishing when the token is no longer valid.
Once subscribed to a stream the user may watch the stream until the stream stops or is terminated, even past the point of token expiration.
Tokens are evaluated when presented to the platform, such as when the SDK attempts to authenticate initially, or following an extended network interruption. If the token has expired, the session will not be authenticated and the application will need to obtain another token.
SDK Initialization with AuthToken
The use of an AuthToken when initializing the SDK varies based on the API Level and client platform. These are summarized in the following tables.
|API Level||Token Usage|
|API Level||Token Usage|
|PCastExpress||PCastExpressFactory.createPCastExpress(pcastExpressOptions); with options built by: PCastExpressFactory.createPCastExpressOptionsBuilder() .withAuthenticationToken|
|RoomExpress||RoomExpressFactory.createRoomExpress(roomExpressOptions); with options built by: RoomExpressFactory.createRoomExpressOptionsBuilder() .withPCastExpressOptions(pcastExpressOptions) where pcastExpressOptions include .withAuthenticationToken|
|ChannelExpress||ChannelExpressFactory.createChannelExpress(channelExpressOptions); with options built by: ChannelExpressFactory.createChannelExpressOptionsBuilder() .withRoomExpressOptions(roomExpressOptions) with roomExpressOptions built by RoomExpressFactory.createRoomExpressOptionsBuilder() .withPCastExpressOptions(pcastExpressOptions) where pcastExpressOptions include .withAuthenticationToken|
|API Level||Token Usage|
|PCastExpress||PhenixPCastExpressFactory.createPCastExpress(pcastExpressOptions) with options built by: PhenixPCastExpressFactory.createPCastExpressOptionsBuilder() .withAuthenticationToken|
|RoomExpress||PhenixRoomExpressFactory.createRoomExpress(roomExpressOptions); with options built by: PhenixRoomExpressFactory.createRoomExpressOptionsBuilder() .withPCastExpressOptions(pcastExpressOptions) where pcastExpressOptions include .withAuthenticationToken|
|ChannelExpress||PhenixChannelExpressFactory.createChannelExpress(channelExpressOptions); with options built by: PhenixChannelExpressFactory.createChannelExpressOptionsBuilder() .withRoomExpressOptions(roomExpressOptions) with roomExpressOptions built by PhenixRoomExpressFactory.createRoomExpressOptionsBuilder() .withPCastExpressOptions(pcastExpressOptions) where pcastExpressOptions include .withAuthenticationToken|