Integrating IAM & SSO

How to connect Experiences to your Identity & Access Management or SSO Service
Integrating IAM or SSO is a common need.
The nature of identity and sign-in depends entirely on the context. Each Experience is different and uses identity in its own way. For example, a voting Experience might use identity as a way to login before voting. Event Centre uses identity to create login gates in front of exclusive content, driving sign-up.
gate within Event Centre
Experiences support Monterosa Identify — our identity management system that can act as an independent identity provider (i.e. can register and manage user accounts) but is more frequently used as an integration interface between your existing identity provider and Monterosa / Interaction Cloud, allowing your existing users to seamlessly use Monterosa Experiences and to help drive new registrations.
Identify instance showing provider options
Monterosa Identify includes adaptors for a number of industry-standard identity management systems, such as:
  • Apple and Google
  • Facebook and Twitter
  • Auth0 and AWS Cognito
  • OpenID
It can also be connected to other solutions and in-house proprietary systems with a custom adaptor - this is a common scenario.
Please contact Sales to arrange for a solutions architect to review your identity solution.

How identity integration works

Identity integration is dictated by context, the configuration of your systems and choices made in the process. Each instance is treated as a project with a solution specification created by our solutions architects with you.
This advice is therefore designed to give you an overview of concepts and methods involved in general terms.


  • Our systems:
    • FanKit: Monterosa 'Experiences' are web apps provided by Monterosa and are built on our FanKit JavaScript/React framework.
    • Identify: The Monterosa identity provider is an interface between your identity system or SSO and our applications. It is called Identify.
  • Your systems:
    • Identity Provider: We refer to your internal identity solution as Identity Provider
    • Client Application: When embedded into your site or native app, we refer to the parent as a Client Application.


There are some pre-requisites 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:
  1. 1.
    A public API endpoint
  2. 2.
    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)
  3. 3.
    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

Providing access tokens

When a user is logged into your site or app, your Client Application must provide the Monterosa App an access token via iFrame or WebView using one of three methods:
  1. 1.
    Query String
  2. 2.
  3. 3.
    Local Storage

iframe & WebView bi-directional communication

Monterosa FanKit is able to communicate back to your Client Application with messages including:
  1. 1.
    Login button CTA
  2. 2.
    Page sizes changing
  3. 3.
    User not valid
  4. 4.
    Other custom CTAs - for instance the opening of an external link
Bi-directional communication can be established using:
  1. 1.
    WebView post messages
  2. 2.
    Deep links related to native apps
Your Client Application developer must put in place a method to capture the post messages or deep links that FanKit generates, and act upon them.