Integrating Identity with your site or app
If you utilise a consumer-facing identity provider (IdP) on your site or app you may wish to integrate that with your Monterosa-powered Experiences via the SDK.
Use Cases
Identity integration unlocks various use cases, depending on the Experience you're using or the front-end application you're creating:
Inline Authentication – seamless detection of an existing “logged in” state, so that the user does not need to login twice to the parent page or app, and then again to the Monterosa Experience.
Access Gating – the application of either “locked content” gates on specific pieces of content, or “You must login to use this Experience” gating for the whole experience.
Cross-device Persistence – the persistence of state across device logins. For example ensuring that a user’s voting history is the same when they are logged in on their phone, and their tablet.
Behavioural Tracking – with consent or legitimate use, the ability to add information about the user’s behaviours to Monterosa / Audience Profiles.
Preference Management – the ability to store user preferences against a persistent ID. For example favourite players, topics or primary language.
Core Concepts
The core concepts you’ll need to be familiar with are:
Identity Provider – the customer’s identity provider, also commonly referred to as their SSO. For example Auth0/Okta, or SAP Gigya.
JWT (JSON Web Tokens) – the token which provides evidence of the user’s logged-in state. This token is passed by the parent app or site, to the Monterosa SDK.
Monterosa Identify – a middlewear component which handles the communication with the customer IdP and with the front-end application.
Identity Adaptor – the plugin that connects Monterosa with the IdP. For example Auth0. This is configured within Monterosa / Studio in a dedicated tab.
Token Transfer – the act of sending the customer’s JWT to the Monterosa SDK. This usually requires a few lines of code in the website or app.
Prerequisites
There are some prerequisites for all integrations. Your application takes responsibility for sign-in flow and managing the state of the user's session.
You must be in control of the 'parent' website or native app and able to make minor changes to it.
Your identity provider must also provide a way for third party systems to validate sessions. Any of the following three methods are supported:
A public API endpoint
A JWK file URL (if the access token is a standard JWT and the SSO Provider is based on standards like OpenID or oAuth2.0)
An access token cryptographic public key that can be stored by our Identify backend to decode it
Note that methods 2 and 3 do not require any exposed endpoint from the SSO Provider and are the preferred way to avoid a high volume of calls.
Integration Strategies
Your integration strategy will depend on your architecture and use case context.
To avoid customisation you'll need to ensure your IdP supports the use of JWT and that you have access to your site and app to create a small amount of code.
There is also a need for Monterosa / Identify to support the IdP, or for your provider to accept JWT in a supported form. Supported are:
Okta's Auth0
SAP Gigya
AWS Cognito
Ping (coming soon)
If your IdP is not supported, contact support and we can scope creating an Identity Adaptor for you.
Connecting your app or site to Monterosa
To connect the Monterosa Experience to your Identity Provider, you will use the Monterosa SDK to act as a bridge.
Set up identity using the SDK & JWTIf you can not use the Monterosa SDK then you may need to handle the token transfer and event handling yourself. Instructions are provided:
Using JWT without the SDKIf your IdP is not supported already, and sometimes if your configuration is unique, we may need to create a custom Identity Adaptor.
Custom Identity AdaptorsLast updated
Was this helpful?