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.

Terms

• 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

Token Types

There are four types of tokens for publishing and streaming:

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 App ID and Secret, as well as information about the Channel or Room.  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.

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.

Open

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.

Open

See the discussion below for details on using the AuthToken when initializing the SDK.

Token Constraints

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 mycompany.com.

User and Stream Constraints

Tokens can optionally be restricted by any combination of the following:

• User Information

  • 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 (see https://github.com/PhenixRTS/EdgeAuth ). The library is currently available for the following platforms:

• Java

• Node.js

• PHP

• DotNet

• Python

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.

Token Expiration

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 table.