Registration & Login

Registration

Before being able to login the user needs to be able to register themselves with the Identity Management System. For this you can use the backstage registration endpoint.

This endpoint accepts the following input:

• username (usually this will be an email address, but it depends on the IMS)
• password
• firstName (can be optional depending on the IMS)
• lastName (can be optional depending on the IMS)

Verification

In some cases IMS's will require email verification in order to allow certain operations. MPP for example requires verification in order to be able to purchase products. In that case the flow is as following:

1. User registers through Backstage
2. IMS will send a verification email with token
3. User is directed to web through email
4. Web application verifies account with the Backstage verification API

When this token has expired (because a user waited too long to verify), you can request a new one through the verification request API.

At this time only MPP supports the verification process.

Login

In order to get an authentication token you can use one of the supported login mechanisms with Backstage:

• Username / Password combo
• Connect Code
• OAuth

Username & Password

The most basic way of logging in with Backstage is by using the username/password combination. In order to perform this login action you essentially only need one API call.

If you've sent the right credentials you will receive a token from Backstage, any other scenario will give you a 4XX error detailing what happened.

Connect Code

Connect code authentication is usually the preferred method of authentication with 10ft devices (SmartTV, AppleTV, Roku, etc.) because actual text-input is cumbersome (especially when using email as usernames). For this reason a connect code is usally preferred, which follows the following steps:

1. User starts auth on application (10ft device).
2. Application gets code from API and displays it.
3. Application (10ft) polls the API until it gets a token.
4. User goes to secondary app (usually mobile or web) and fills in the code.
5. Secondary app verifies code through the API.
6. Token received and user is logged in.

As of right now Backstage requires the IMS to have explicit support for this type of authentication. However we're working on also supporting this flow even without explicit support.

None of the IMS' currently have support for this.

OAuth

OAuth allows you to login with external systems (Facebook, Google, etc.) outside of the normal flow of authentication.

1. User clicks "login with ..." button.
2. Application requests redirect URL from API.
3. Application opens browser with redirect URL.
4. User logs in via browser with provider.
5. User gets redirected back to app with token.
6. Application exchanges token for actual authentication token.

Currently only FlowID (CWC/FlowSports) is supported in this flow as a provider. However the Backstage team plans to add support for more providers, in which case the API will require the provider to use as a parameter.

Profiles

Once you've logged in through the Backstage API you'll automatically have a default profile assigned. The token that you've received is tied into this profile and in order to switch to a profile you'll have to request a new token through the switch profile API.

This endpoint requires you to send the profile ID you want to select, which you can get from the profile list API. This will give you a list of all profiles, including a name and image you can render on your switcher.

Once you've received your new token and send it in subsequent calls Backstage will automatically process the selected profile for you and store things like favourites, player events, etc. under the selected profile.