MemorySyncMemorySync
Enterprise

SSO

Federated single sign-on for dashboard users via SAML 2.0 or OpenID Connect. SSO centralizes authentication through your existing identity provider, removing the need for separate passwords and giving your security team full control over who can access MemorySync.

What is SSO

Single Sign-On (SSO) lets your team authenticate to MemorySync using credentials managed by your organization's identity provider (IdP). Instead of creating a separate MemorySync password, users sign in through your IdP — the same way they access email, Slack, or any other corporate tool.

MemorySync supports two federation protocols:

  • SAML 2.0. The industry standard for enterprise SSO. MemorySync acts as the Service Provider (SP) and your IdP sends signed assertions after authenticating the user. Full XML signature verification is performed on every login.
  • OpenID Connect (OIDC). A modern, OAuth 2.0-based protocol. MemorySync uses the Authorization Code flow with PKCE for maximum security. Login state tokens have a short, fixed lifetime so abandoned login attempts do not linger.
Why both?
Some IdPs (like Google Workspace) only support OIDC. Others (like legacy OneLogin setups) only support SAML. MemorySync supports both so you can use whichever your IdP prefers.

Supported Identity Providers

MemorySync supports the following identity providers with pre-built templates for quick configuration.

ProviderProtocolNotes
OktaSAMLPre-built template. Supports group-to-role mapping out of the box.
Microsoft Entra IDOIDCPre-built template. Works with Microsoft’s enterprise app gallery.
Google WorkspaceOIDCPre-built template. Uses Google’s OAuth 2.0 endpoints.
OneLoginSAMLPre-built template. Signed assertions supported with the algorithms OneLogin offers.
Auth0OIDCPre-built template. Works with Auth0 enterprise connections.

Setup Guide

  1. 1In MemorySync: Settings → SSO → Configure. Pick your provider type (SAML or OIDC) and select a provider template or choose Custom.
  2. 2MemorySync generates your SP Entity ID, ACS URL, and SP Metadata URL. Copy these into your IdP’s application configuration.
  3. 3In your IdP: paste the IdP Entity ID, SSO URL, and signing certificate (for SAML) or Client ID, Client Secret, and Issuer URL (for OIDC) back into MemorySync.
  4. 4Test the connection using MemorySync’s built-in test login. This validates the full round-trip without affecting existing users.
  5. 5Enable SSO enforcement when ready. Existing password users keep working until you flip the enforce_sso toggle.

Domain Verification

Before SSO can be enforced for an email domain, you must prove ownership of that domain via a DNS TXT record. This prevents rogue organizations from hijacking authentication for domains they don’t own.

  • Unique token. MemorySync generates a high-entropy DNS token for each domain. Add it as a TXT record at your domain registrar.
  • Verification. MemorySync checks the DNS record directly. Verification attempts and errors are tracked, so you can see exactly what went wrong if verification fails.
  • Global uniqueness. A domain can only be verified by one organization. If acme.com is already verified by Org A, Org B cannot claim it. This prevents cross-organization impersonation.
  • Provider linking. Once verified, a domain can be linked to a specific identity provider configuration for that organization.

SSO Settings Reference

SettingTypeDefaultDescription
enforce_ssoboolfalseWhen enabled, password-based login is blocked for all users in the organization. Only SSO login is allowed.
allow_password_fallbackbooltrueWhen SSO enforcement is on, this allows a grace period where existing password users can still log in. Disable for strict SSO-only access.
jit_provisioning_enabledbooltrueAutomatically create a MemorySync account when a user logs in via SSO for the first time (Just-In-Time provisioning).
jit_default_rolestringdeveloperThe role assigned to new users created via JIT provisioning. Can be overridden by group-to-role mapping.
sso_session_duration_hoursint24How long an SSO session lasts before the user must re-authenticate through the IdP.

Attribute Mapping

When a user authenticates via SSO, MemorySync extracts identity attributes from the IdP’s assertion (SAML) or ID token (OIDC). The default mapping covers the most common attribute names:

MemorySync FieldDefault IdP AttributeRequired
emailemailYes
namenameNo
given_namegiven_nameNo
family_namefamily_nameNo

You can customize the mapping in Settings → SSO → Attribute Mapping if your IdP uses non-standard attribute names (for example, mail instead of email).

Group-to-role mapping
If your IdP sends a groups attribute, you can map IdP group names to MemorySync roles. When a user logs in, their role is set based on their group membership. This is configured per identity provider and overrides the default JIT role.

Troubleshooting

  • Login loops back to IdP. The ACS URL in your IdP does not match the one generated by MemorySync. Copy the SP ACS URL from Settings → SSO and paste it exactly into your IdP’s configuration.
  • Signature verification failed. The IdP’s signing certificate in MemorySync does not match the one the IdP is actually using. Re-download the certificate from your IdP and update it in MemorySync. Check the certificate expiry date in Settings → SSO — expired certificates are the most common cause.
  • User logged in but has no permissions. The user’s IdP groups do not match any group-to-role mapping, and the JIT default role may be too restrictive. Add a default role mapping or adjust jit_default_role.
  • Stale group membership. SSO reads groups only at login time. If you change a user’s groups in the IdP, they need to log out and back in to pick up the change. For real-time sync, pair SSO with SCIM provisioning.
  • Provider shows as “degraded” or “down”. MemorySync runs periodic health checks against your IdP’s metadata endpoint. If the IdP is temporarily unreachable, the provider status reflects that. Check your IdP’s status page and the health check latency in Settings → SSO.
  • OIDC login expired. OIDC login state tokens have a short lifetime. If a user takes too long to complete login at the IdP, the state expires — they can simply retry the login.