Using EdgeAuth

Once you have integrated the EdgeAuth library into your backend, generate tokens as described below.

• 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:

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.

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

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

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.

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.

Authentication tokens are generated using a POST request as shown.

Example request for creating an authentication token

1POST /pcast/auth HTTP/1.1
2Host: pcast.phenixrts.com
3Accept: application/json
4Content-Type: application/json
5Content-Length: 68
6
7{
8    "applicationId": "<applicationId>",
9    "secret": "<secret>"
10}

1$ curl https://pcast.phenixrts.com/pcast/auth \
2-H "Accept: application/json" \
3-H "Content-Type: application/json" \
4-H "Content-Length: 68" \
5-X POST \
6-d '{
7        "applicationId": "<applicationId>",
8        "secret": "<secret>"
9        "capabilities": ["<capability>"]
10    }'

Request Headers

Request Payload

Supported Authentication Capabilities

The platform will return a successful response that contains a "status" and an "authenticationToken" field. The HTTP status code is set according to the "status" field.

HTTP/1.1 200 OK

Response Headers

Example response for authentication token requests

1HTTP/1.1 200 OK
2Content-Type: application/json; charset=utf-8
3Content-Length: 52
4
5{"status":"ok","authenticationToken":"us-east#VaTd"}

1{
2    "status":"ok",
3    "authenticationToken":"us-east#VaTd"
4}

Response Fields

Status Codes

Stream tokens are generated sending a POST request as shown.

If you provide an "originStreamId", a view token is generated. Otherwise, a publish token is generated.

Example request for creating a stream token

1POST /pcast/stream HTTP/1.1
2Host: pcast.phenixrts.com
3Accept: application/json
4Content-Type: application/json
5Content-Length: 194
6
7{
8    "applicationId": "<applicationId>",
9    "secret": "<secret>",
10    "sessionId": "<sessionId>",
11    "originStreamId": "<originStreamId>",
12    "capabilities": [
13        "<capability>"
14    ]
15}

1$ curl https://pcast.phenixrts.com/pcast/stream \
2-H "Accept: application/json" \
3-H "Content-Type: application/json" \
4-H "Content-Length: 138" \
5-X POST \
6-d '{
7        "applicationId": "<applicationId>",
8        "secret": "<secret>",
9        "sessionId": "<sessionId>",
10        "originStreamId": "<originStreamId>",
11        "capabilities": ["<capability>"]
12    }'

Request Headers

Request Fields

The platform will return a successful response that contains a "status" and a "streamToken" field. The HTTP status code is set according to the "status" field.

Response Headers

Example response for stream token requests

1HTTP/1.1 200 OK
2Content-Type: application/json; charset=utf-8
3Content-Length: 44
4
5{"status":"ok","streamToken":"us-east#C1Nl"}

1{
2    "status":"ok",
3    "streamToken":"us-east#C1Nl"
4}

Response Fields

Status Codes