SSO, Federation & Security FAQ¶

This page answers the questions most commonly raised by IT and security teams evaluating how Lime CRM integrates with an external identity provider (IdP). It complements the configuration guides:

Identity and authentication¶

Which authentication protocols are supported?¶

Lime CRM authenticates users with OpenID Connect (OIDC) on top of OAuth 2.0, using the Authorization Code flow. The supported identity providers are Microsoft Entra ID (Azure AD) and any standards-compliant generic OpenID Connect provider.

SAML 2.0 is not supported, and there is no LDAP-based login. (The legacy "LADI" Windows Active Directory integration is deprecated.)

In this integration Lime CRM acts as an OIDC Relying Party (RP) — the client that delegates authentication to your IdP.

Can Lime CRM act as a Service Provider (SP) in a federation?¶

Yes. As an OIDC Relying Party, Lime CRM receives authenticated identities from your external IdP — functionally the same role as a SAML Service Provider, but over OIDC rather than SAML. Lime CRM is not a SAML SP.

Which attributes are required to identify and authenticate a user?¶

A single, stable claim from the ID token that maps to a Lime CRM user. By default:

Username ← the email claim
External ID ← the oid claim (the IdP's immutable object identifier)

The mapping is configurable. We recommend mapping the external ID to the immutable oid claim rather than to mutable claims such as email. National identifiers (for example a personal identity number or HSA-id) are not required and are not stored. See user authentication based on token claims.

Do you support Single Sign-On (SSO) and Single Logout (SLO)? How are sessions handled?¶

SSO: yes — via OIDC against your IdP.

SLO: partially. The behavior depends on who initiates the logout:

RP-initiated logout (supported): when a user logs out of Lime CRM, the browser is redirected (front-channel) to the IdP's end-session endpoint so the IdP session is also ended. For a generic OpenID provider this requires the IdP to publish an end_session_endpoint; otherwise only the local Lime CRM session is ended.
IdP-initiated logout (not supported): Lime CRM does not implement the OIDC Front-Channel Logout or Back-Channel Logout specifications — the IdP-initiated logout callbacks — so the IdP cannot push a logout to Lime CRM. (This is distinct from the RP-initiated front-channel redirect above, which is supported.)
Enforcing an IdP-side change (Microsoft Entra ID only): with token_validation_enabled, Lime CRM re-validates the session against Entra by attempting a token refresh. Entra invalidates the user's refresh tokens immediately on a critical event — the account being disabled or deleted, a password reset, or an administrator revoking the refresh tokens — and when the user is removed from the Enterprise Application; the next refresh then fails and the Lime CRM session is ended. By default Lime re-validates when the access token expires (Entra access tokens last ~1 hour), so the change is enforced within roughly that window; time_to_expiration sets a shorter Lime-side re-validation interval to enforce sooner (it controls how often Lime re-checks, not Entra's token lifetime). This is the standard OAuth2 refresh-token revocation model, not Microsoft Continuous Access Evaluation (CAE) — which delivers near-real-time critical-event revocation but requires a CAE-aware resource. This mechanism is not available for the generic OpenID provider.

Sessions: the default session timeout is 24 hours and active users' sessions are extended automatically; the session cookie lasts 31 days by default; idle sessions are ended automatically. To force more frequent re-authentication, disable automatic session extension and lower the timeout. See Session configuration.

Federation and directory integration¶

How does Lime CRM integrate with an external directory service?¶

Through SCIM 2.0. Lime CRM exposes a SCIM endpoint for user and group provisioning, most commonly driven by Microsoft Entra ID provisioning. LDAP and SAML assertions are not used for directory integration. See User provisioning (SCIM).

Lime CRM has no built-in integration with national eID schemes such as Freja eID, Freja OrganisationsID or BankID, nor with federations such as Sambi or Skolfederation.

However, because Lime CRM delegates authentication to your OIDC IdP, any login method that your IdP brokers is used transparently by Lime CRM. So if your IdP offers BankID or Freja eID — for example through an OIDC-capable broker — users can authenticate that way without Lime CRM integrating the eID directly.

Sambi and Skolfederation are SAML 2.0 federations. Because Lime CRM is not a SAML SP, it cannot join them directly; that would require an intermediary IdP that bridges the SAML federation to OIDC.

How are user accounts provisioned and deprovisioned?¶

Automatically, via SCIM 2.0 (typically Microsoft Entra ID provisioning): users and groups can be created and updated, and users can be deactivated. See User provisioning (SCIM).

To force an immediate sign-out when access must be revoked, rely on one of the enforcement mechanisms described in the SSO/SLO answer above: for Microsoft Entra ID, disabling the user or removing them from the Enterprise Application is enforced via token_validation_enabled (within roughly the access-token lifetime, ~1 hour); and an administrator-initiated deactivation of the user in Lime CRM ends that user's active sessions.

What are the requirements on the IdP for federation to work?¶

The IdP must support the OIDC Authorization Code flow as a confidential client. Specifically:

Generic OpenID: a discovery/metadata URL (.well-known/openid-configuration, recommended) or explicit authorize/token/userinfo endpoints; a client_id and client_secret; the Lime CRM redirect URI registered with the IdP; and a claim usable as username or external ID.
Microsoft Entra ID: tenant ID, client_id, client_secret, the redirect URI registered, and the Microsoft Graph User.Read delegated permission with admin consent.

There is no SAML NameID format or SP metadata document, because the integration is OIDC, not SAML.

Technology and security¶

Do you support MFA, and can it be delegated to the IdP?¶

Multi-factor authentication is not a built-in Lime CRM feature; it is delegated to your IdP. Any MFA or conditional-access policy your IdP enforces applies during login.

How are attributes and personal data handled in the federation? What is stored or logged?¶

Lime CRM persists only the username and external ID taken from the ID token; other claims are used transiently during login and are not stored. National identifiers are not stored. Mapping the external ID to the immutable oid claim keeps the stored identifier pseudonymous.

Tokens (the ID token and refresh token) are held server-side in the session store for the lifetime of the session and are cleared on logout; the access token itself is not persisted. Token values and sensitive fields (tokens, secrets, passwords, personal identity numbers) are masked in application logs; authentication logging records user and session identifiers, not token values or personal data from claims.

All traffic is protected with TLS (see the security-mechanisms answer below). On Lime Cloud, server-side TLS certificates are managed automatically via AWS Certificate Manager.

How are certificate rotation and metadata updates handled?¶

For OIDC, the IdP's signing keys (JWKS) and discovery metadata are fetched from the IdP automatically — there is no manual key handling on the Lime CRM side. The Lime-side client secret is rotated manually by updating the configuration; an optional client_secret_expiration_date is used for monitoring and expiry alerts. SAML certificate and metadata concepts do not apply.

What security mechanisms protect the authentication flow?¶

TLS 1.2 / 1.3 for all traffic.
OAuth 2.0 Authorization Code flow with a confidential client (client secret).
CSRF protection via the OAuth state parameter, and a nonce on the OIDC request.
ID-token validation: for Microsoft Entra ID, the token signature, audience (aud = client ID), issuer and nonce are validated. For a generic OpenID provider, the ID-token signature is validated against the IdP's published keys (JWKS) when a discovery/metadata URL is configured (recommended).