Introduction
Every request your frontend makes to the Content Delivery API on behalf of a signed-in end-user carries anX-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
- The end-user signs in on your app through your identity provider, which returns an ID token to the app.
- Your app sends the ID token to the Content Delivery API.
- 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.
- Motto returns a Motto token and a refresh token to your app.
- Your app sends the Motto token in the
X-Motto-Tokenheader on every request to the Content Delivery API.
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
RS256orES256 - 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.- Navigate to OTT → Integrations → OpenID Connect.
- 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.
- Open the Advanced section and scroll down to ID Token Exchange.
- Turn on Allow ID Token Exchange.
- 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.
- Click Publish.
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.
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 itsexp claim.
When the Motto token has expired or is about to expire, exchange the refresh token for a new pair:
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.Create tokens on your server
Create tokens on your server
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 anAuthorization: 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:- The end-user signs in on your frontend or mobile app, using your own user management system.
- Your client sends a request to your server, authenticated with the session from your own system.
- 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.
- Your server returns the Motto token to the client.
- Your client sends the token in the
X-Motto-Tokenheader on every request to the Content Delivery API.
- 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: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. UseROLE_DEFAULTfor regular viewers.ttl(query, optional) — How long the token stays valid, in seconds with anssuffix (e.g.86400sfor one day). Defaults to one week.
3. Return the token to the client
Send thetoken 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.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
ttllimits 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.

