Authentication & SSO

​

Authentication Layers

Reelevant separates authentication into two distinct layers:

​

Content Integration (Public)

Integration URLs — image tags, redirection links, and Runner endpoints — are publicly accessible. No authentication header or token is required at request time. Customer identifiers are passed as URL query parameters (e.g. uid, rlvt-u). These are public by design: they appear in email HTML source, browser history, and proxy logs. Use opaque customer IDs rather than email addresses or other PII.

​

Platform Access

​

Email and Password

Standard login at app.reelevant.com. Users authenticate with their email address and password. Multi-factor authentication (MFA) is supported.

​

Single Sign-On (SSO)

Reelevant supports SSO integration with your organisation’s identity provider. When SSO is configured, users are automatically redirected to your IdP for authentication — no separate Reelevant password is required. Supported protocol:

• SAML 2.0 — Standard enterprise SSO protocol

SSO configuration includes: User provisioning: Three options, which can be combined:

​

JIT Provisioning

The SSO user mode decides what happens when a valid assertion arrives for an email that has no Reelevant account: A JIT-created user gets its profile from your attribute mapping, and its role and Teams from the pending invitation when there is one, otherwise from the company defaults. An invitation’s role and Teams are re-validated against the company before they are honoured. Creation is recorded in the audit log as an sso event attributed to sso-jit. JIT covers arrivals only: profile drift, role and Team changes, and departures are not propagated, since the IdP never contacts Reelevant except during a login. SCIM covers all four.

​

SCIM 2.0

SCIM 2.0 (RFC 7643/7644) covers /Users and /Groups with a company-scoped bearer token, and works with the standard Okta and Microsoft Entra ID connectors. IdP groups map to Reelevant Teams, and roles can be driven from a SCIM role attribute or from group-to-role mappings. Deactivation revokes sessions immediately. Every provisioning request is recorded in the in-product audit log. See the SCIM developer reference for the protocol detail, or the setup guide for the configuration options.

​

Authorisation Model

Once authenticated, access is enforced through RBAC and ABAC:

​

RBAC (Role-Based Access Control)

Each user is assigned a role that defines permitted actions on resource types:

​

ABAC (Attribute-Based Access Control)

Permissions are further scoped by attributes:

• Company — Tenant isolation ensures users only access their organisation’s resources
• Team — Resources are assigned to Teams; users only see resources belonging to their Teams

This means a user with the “Editor” role in “Team Marketing” can edit Workflows assigned to that team, but cannot see or modify Workflows belonging to “Team CRM”. See Permissions for the full access model.

​

API Authentication

​

Platform APIs

Reelevant treats its APIs as first-class citizens alongside the UI. All platform capabilities are accessible programmatically via REST APIs:

• OAuth 2.0 Bearer tokens for authentication
• Tokens are scoped per environment (staging / production)
• Tokens are managed in the platform under Account settings
• All API requests require the Authorization: Bearer {token} header

See API Authentication for OAuth 2.0 flows and token management, and the API Reference for full endpoint documentation.

​

Next Steps