Authentication in external integrations

Storyteq CMP supports authentication in external integrations through a service called the Identity Broker. The Identity Broker allows users to sign in to external integrations, such as the CMP Asset Picker, using their existing company credentials, including SSO. It routes each user to the correct sign-in provider automatically.

To sign in to the CMP Asset Picker, see Sign in to the CMP Asset Picker. The rest of this page explains how the authentication system works, and is intended for administrators and implementers.

What the Identity Broker does

The Identity Broker is a lightweight proxy service built by Storyteq. It sits between an external integration and the appropriate identity provider for a given tenant.

When a user attempts to sign in to an external integration, the Identity Broker receives the request, identifies which identity provider the tenant uses and the region they’re in, and constructs a redirect URL to that provider’s sign-in page. The user authenticates with their own identity provider directly. The integration never handles the user’s credentials.

The Identity Broker supports both browser-based applications, such as Jira, and native desktop applications, such as Figma.

Why the Identity Broker exists

Before the Identity Broker, external integrations required users to authenticate using a CMP username and password, entered directly within the integration itself. This prevented many enterprise clients, who authenticate via SSO, from signing in to external integrations at all. It also meant credentials were handled by the third-party application, rather than a trusted identity provider.

The Identity Broker solves both problems by redirecting users to their own identity provider to authenticate, rather than handling credentials within the integration itself.

Identity provider routing

CMP Professional uses Keycloak as its identity provider. Existing clients provisioned on LUMA are gradually being migrated to Keycloak. During this transition period, both LUMA and Keycloak are used concurrently.

Because different tenants may be using different identification provision, the Identity Broker determines the appropriate provider for each authentication request and routes the user accordingly.

How authentication works

The Identity Broker uses the OpenID Connect protocol, an identity layer built on top of OAuth 2.0. The authentication flow works as follows:

  1. The user initiates sign-in within the external integration.

  2. The integration redirects the user to the Identity Broker, which constructs a redirect URL to the appropriate identity provider.

  3. A new browser tab opens, displaying the identity provider’s sign-in page.

  4. The user authenticates using their own credentials or SSO.

  5. The identity provider returns a temporary authorisation code to the integration.

  6. The integration exchanges the code for a short-lived access token and a refresh token.

  7. The integration uses the access token to make requests on behalf of the user.

  8. The refresh token is used periodically to obtain a new access token, keeping the user signed in.

Why authentication opens in a new tab

Rather than displaying the sign-in experience within the integration itself, for example in a modal, the Identity Broker opens authentication in a new browser tab. This approach protects user credentials by ensuring they are only ever entered on the identity provider’s own domain, where the URL is visible to the user. It also isolates the authentication flow from the main application state and ensures compatibility with browser security restrictions that can prevent credential entry inside embedded frames.

Proof Key for Code Exchange (PKCE)

The Identity Broker implements Proof Key for Code Exchange (PKCE). PKCE is a security extension to the OAuth flow that protects against authorisation code interception attacks and cross-site request forgery. It does this by generating a one-time secret at the start of the flow that must be verified when the authorisation code is exchanged for a token, ensuring that only the originating application can complete the exchange.

Polling and timeout

Because authentication happens in a separate browser tab, the integration cannot receive the result of the sign-in directly. Instead, the integration polls the Identity Broker to detect when authentication has been completed.

The integrator is responsible for determining when to abandon polling and time out the session. We recommend a 5-minute window, after which the integration should return to its original state so the user can restart the sign-in process.

If the user is already authenticated with their identity provider, the Identity Broker detects this and returns them to the integration in a signed-in state without requiring them to sign in again.

Benefits over legacy authentication

The Identity Broker provides the following improvements over the legacy credential-based approach.

  • Credential security: User credentials are entered only on the identity provider’s own sign-in page. The integration never has access to them.

  • Visible sign-in URL: Users can see the URL of the page they are signing in to, both in browser and desktop applications. This allows them to verify they are on a legitimate sign-in page.

  • SSO support: Users who authenticate via their company’s own identity provider can now sign in to external integrations without needing a separate CMP username and password.

  • Seamless re-authentication: Users who are already signed in are not prompted to sign in again.

  • Short-lived tokens: Access tokens are short-lived, reducing the window of risk if a token is compromised. The refresh token mechanism keeps users signed in without requiring them to re-authenticate manually.