Skip to main content

Introduction

Every request your frontend makes to the Content Delivery API on behalf of a signed-in end-user carries an X-Motto-Token header. This token tells Motto who the viewer is, so Motto can check what they are entitled to watch, such as a pay-per-view event or a subscription. Normally, Motto issues this token for you when the end-user signs in. If you run your own user management system, Motto does not see the sign-in, so your platform has to obtain the token another way.

Choose the right approach

Pick the first option that fits your situation:
  • Motto’s native user system — Motto handles sign-up, sign-in and tokens for you. This is the default option.
  • Motto’s built-in OIDC integration — If your identity provider supports OpenID Connect, connect it in the Motto Studio under OTT → Integrations → OpenID Connect. Motto runs the sign-in with your identity provider, your end-users keep their existing credentials, and Motto issues the tokens.
  • OIDC ID token exchange — If your apps already run their own OpenID Connect sign-in, they exchange the ID token your identity provider issued for a Motto token. No server-side code is needed. This guide explains how.
  • Tokens created on your server — If your user management system does not support OpenID Connect, for example a proprietary customer database or a legacy membership platform, your server creates the tokens through the Studio API. See Advanced: create tokens on your server.

Exchange an OIDC ID token

Use the ID token exchange when your web or mobile app signs the end-user in with your identity provider itself, for example through an OpenID Connect library in your iOS or Android app. After the sign-in, your identity provider hands the app an ID token: a JWT, signed by your identity provider, that states who the end-user is. Your app sends this ID token to the Content Delivery API and receives a Motto token in return.

How it works

  1. The end-user signs in on your app through your identity provider, which returns an ID token to the app.
  2. Your app sends the ID token to the Content Delivery API.
  3. Motto verifies the ID token against your OIDC integration: its signature against your identity provider’s published keys, its issuer, its audience and its expiry.
  4. Motto returns a Motto token and a refresh token to your app.
  5. Your app sends the Motto token in the X-Motto-Token header on every request to the Content Delivery API.
Motto identifies the end-user by the user ID claim of your OIDC integration (sub by default). An end-user who signs in through Motto’s built-in OIDC flow on one platform and through your app’s own sign-in on another is therefore the same Motto user, with the same entitlements and purchases.

Prerequisites

  • An identity provider that supports OpenID Connect and signs its ID tokens with an asymmetric algorithm, such as RS256 or ES256
  • Your identity provider’s issuer URL, the URL at which it publishes its OpenID Connect discovery document
  • The client IDs that your apps use at your identity provider
  • Your project’s public key, the same one your app already sends to the Content Delivery API. In the Motto Studio, click your user profile in the top-right corner, then go to API Keys → Project public key.

Get Started

The following steps will guide you through enabling the ID token exchange via the Studio.
  1. Navigate to OTT → Integrations → OpenID Connect.
  2. Fill in the fields the exchange needs, unless your integration already has them:
    • Provider Name — A name for your identity provider, for your own reference.
    • Issuer URL — Your identity provider’s issuer URL. Motto reads your identity provider’s signing keys from it, and only accepts ID tokens issued by it.
    • Client ID — The client ID of one of your apps at your identity provider. Motto accepts ID tokens issued to this client.
  3. Open the Advanced section and scroll down to ID Token Exchange.
  4. Turn on Allow ID Token Exchange.
  5. Under Additional Client IDs, enter the client IDs of your other apps at your identity provider, separated by commas. You can skip this if all your apps use the client ID from step 2.
  6. Click Publish.
The other fields are optional for the exchange. Client Secret, Scopes and Response Type are only used by Motto’s own sign-in flow. The Studio marks Client Secret as required because Motto’s own sign-in flow needs it, but the ID token exchange does not, so you can leave it empty if you only use the exchange. If your identity provider does not put the end-user’s ID, email, name or picture in the standard claims, set User ID Claim, Email Claim, Name Claim or Picture Claim in the Advanced section.
Choose the User ID Claim before end-users start signing in, and do not change it afterwards. Motto recognises returning end-users by this claim, so changing it turns every end-user into a new Motto user without their entitlements and purchases.
The ID token exchange works independently of Enable Integration, which controls Motto’s own sign-in flow. You can allow the exchange without offering Motto’s sign-in, and the other way around.
Once the exchange is enabled, call it from your app right after the end-user signs in with your identity provider:
The response contains the Motto token and a refresh token:
Send the ID token, not the access token. Motto refuses access tokens, as well as ID tokens that were issued to a client ID your integration does not list.
Exchange the ID token as soon as your app receives it. ID tokens are usually valid for a short time only, and Motto refuses expired ones.

Keep the end-user signed in

Store the Motto token and the refresh token the same way you store your own session credentials, and reuse the Motto token for as long as it is valid. The token is a JWT, so your app can read the expiry time from its exp claim. When the Motto token has expired or is about to expire, exchange the refresh token for a new pair:
The response has the same shape as the exchange. Replace both stored tokens with the new ones.
Do not exchange or refresh tokens on every page load or app launch. These calls are rate-limited, and unnecessary calls slow down your platform and can cause requests to be rejected.

Advanced: create tokens on your server

If your user management system does not support OpenID Connect, your server can create Motto tokens itself through the Studio API. This requires you to build, secure and maintain server-side code, so only use it when none of the options above fit your situation.

How it works

The token is created by the Create User Token endpoint of the Studio API. The Studio API is meant for trusted parties only. Every call requires an Authorization: Bearer header containing your secret API token, which grants access to your entire Motto organization.This means your web or mobile client can never call the endpoint directly. Anything shipped to a browser or mobile device can be extracted, including your API token. Instead, the exchange has to happen in a secure server-side environment that you control:
  1. The end-user signs in on your frontend or mobile app, using your own user management system.
  2. Your client sends a request to your server, authenticated with the session from your own system.
  3. Your server verifies that session, then calls the Studio API with your secret API token to create a Motto-signed token for that end-user.
  4. Your server returns the Motto token to the client.
  5. Your client sends the token in the X-Motto-Token header on every request to the Content Delivery API.
You have two options for the secure environment:
  • Your own backend — Add an endpoint to a backend service you already operate, or deploy a small dedicated service for this purpose. This works for every type of client, including iOS, Android and TV apps.
  • The server side of your web framework — If your frontend runs server-side code, such as API routes or server actions in Next.js, you can build the exchange there. The code runs on your server, so the API token never reaches the browser.

Prerequisites

  • A Motto project ID for the project your end-users watch content in
  • A Studio API token, available on the API credentials page of the Motto Studio
  • A server-side environment where you can store the API token as a secret, such as an environment variable or a secrets manager
  • A way for your server to verify which end-user is signed in, using your own user management system

1. Pick a user ID

Choose the identifier that Motto will know your end-user by. Use a stable, unique ID from your own system, such as a database primary key. Motto uses this ID for everything it knows about the end-user, such as their entitlements and purchases, and their viewing behaviour in user analytics. It must therefore never change for the same end-user.You do not need to create the user in Motto first. Motto accepts any user ID, even one it has never seen before.

2. Create the token on your server

After your server has verified the end-user’s session, call the Create User Token endpoint:
The endpoint accepts the following parameters:
  • user_id (path, required) — The end-user’s ID from step 1.
  • project_id (query, required) — The Motto project the token is valid for.
  • role (query, required) — The end-user’s role. Use ROLE_DEFAULT for regular viewers.
  • ttl (query, optional) — How long the token stays valid, in seconds with an s suffix (e.g. 86400s for one day). Defaults to one week.
The response contains the Motto-signed token and a refresh token:
If you are using Next.js, a route handler for the exchange looks like this:

3. Return the token to the client

Send the token from step 2 back to your client. Store it the same way you store your own session credentials, and reuse it for as long as it is valid.Only request a new token from your server once the current one has expired or is about to expire. The token is a JWT, so your client can read the expiry time from its exp claim.
Do not exchange a new token on every page load or app launch. Minting tokens is a call to the Studio API, which is rate-limited, and unnecessary calls slow down your platform and can cause requests to be rejected.

4. Use the token in the Content Delivery API

Add the token to every request your client makes to the Content Delivery API on behalf of the end-user:

Security considerations

Your server issues tokens for any user ID it chooses, so the security of your platform depends on how you build the exchange:
  • Keep the API token on the server. Never ship it in a frontend bundle, a mobile app or a public repository.
  • Derive the user ID from a verified session. Never accept a user ID sent by the client, or anyone could request a token for another end-user and access their purchases.
  • Keep token lifetimes short. A shorter ttl limits the damage if a token leaks. Balance this against how often your clients need to request a new token, since they only request one when the current token has (nearly) expired.
The Studio API token belongs to the Motto account you are signed in to, and grants that account’s full access. Anyone who obtains it can manage your entire Motto organization.

Next Steps

Learn more about the endpoints and concepts used in this guide: