Single Sign-On Overview

Recomly supports two distinct sign-in modes beyond username and password: Google sign-in (built in for all accounts) and enterprise SSO via SAML or OIDC (available on plans with the SSO feature).

These are independent. You do not need the SSO feature to use Google sign-in, and configuring a SAML or OIDC provider does not affect how Google sign-in works.

A Sign in with Google button is available on the Recomly login page for all users — no admin setup or SSO entitlement required.

New users can sign up by clicking the Google button. Recomly creates their account and organization automatically on first sign-in.
Existing email/password users can link their Google account by clicking the Google button and completing the OAuth flow. Once linked, they can sign in with either method.

See Google sign-in for details and important caveats about identity linking.

Enterprise SSO (SAML / OIDC)

Enterprise SSO lets your team sign in using your organization's identity provider — such as Okta, Azure AD, or any SAML 2.0 or OIDC-compatible IdP. This requires the SSO feature on your Recomly plan.

Unlike Google sign-in, enterprise SSO providers are configured by an admin in the SSO Providers section of the Recomly dashboard. Each provider is mapped to one or more email domains. When a user enters their email at login, Recomly checks the domain and redirects them to the matching provider.

Protocol	Guide
SAML 2.0	SAML
OIDC	OIDC

SAML/OIDC users must be invited by an admin before their first login. A new user who attempts to sign in via an enterprise SSO provider without an existing invitation will be blocked.
Enterprise SSO requires the SSO feature entitlement on your plan. If your plan does not include it, the SSO Providers section will not be accessible.

Email domain uniqueness

Each email domain can only be assigned to one SSO provider at a time, globally across all of Recomly. This applies in two ways:

Within your organization — you cannot assign the same domain (e.g. acme.com) to both a SAML provider and an OIDC provider simultaneously. Each domain can only route to one provider.
Across organizations — if another Recomly organization has already claimed acme.com, your organization cannot use that domain in an SSO configuration.

If you attempt to save a provider with a domain that is already in use, Recomly will return an error. Contact support@recomly.com if you believe a domain has been claimed incorrectly.

Identity linking across multiple providers

A single Recomly account can be linked to more than one sign-in method. This happens automatically when the same email address appears in multiple identity providers.

Example: A user whose Recomly account email is tom@acme.com has previously signed in with Google. If your organization later configures a SAML provider (e.g. Okta or OneLogin) and tom@acme.com exists in that directory too, Recomly will link the SAML identity to the same account on first SAML sign-in. From then on, tom@acme.com can authenticate via Google or via the SAML provider interchangeably.

This linking happens silently — neither the user nor the admin receives a notification.

What this means in practice

A user with both Google and a corporate SSO identity at the same email address will end up with a single Recomly account linked to both. This is usually the desired behavior.
Because linking is email-based, it is important that your identity providers agree on the canonical email address for each user. If the same person has different email formats in different providers (e.g. tom@acme.com vs. thomas@acme.com), they will end up with separate Recomly accounts.
Linked identities cannot be unlinked through the app. If an incorrect link is made, the only recovery path is to delete the user and re-invite them.

Enterprise SSO (SAML/OIDC) is designed for company-managed domains registered in your SSO provider configuration (e.g. acme.com). It is not compatible with accounts that were created via the Sign in with Google button.

If the account owner signed up for Recomly using Google sign-in (e.g. tom@acme.com via Google OAuth), and later configures a SAML or OIDC provider whose directory also contains tom@acme.com, that account cannot sign in via the enterprise SSO provider. The SSO domain validation guard will block the attempt because the email's domain must be registered to an SSO provider in Recomly — and a Google sign-in account, even on a company domain, is not the same as an enterprise SSO identity.

In practice this scenario does not arise for normal use: the account owner who sets up the organization typically uses Google sign-in for their own access, while enterprise SSO is configured for the rest of the team on a company domain. If you need the account owner's email to work with enterprise SSO as well, invite them as a user in Recomly and they will be able to link their SSO identity on first sign-in.

The first time an invited user signs in via a SAML or OIDC provider, they will be redirected back to the Recomly login page after authenticating with their identity provider. This is expected behavior — it is not an error.

What is happening: Recomly detects the new SSO identity, links it to the user's existing invited account, and then redirects back to the login page to complete the flow cleanly. The login page displays a confirmation message:

Your SSO identity has been linked to your account. Click SSO above to finish signing in.

The user simply clicks the SSO button a second time and signs in normally. All subsequent logins go through without interruption.

This one-time redirect only occurs on the very first SSO sign-in for a given account. If you are rolling out SSO to your team, it is worth letting users know in advance so they are not surprised by the redirect.

Deleting a provider with active users

Deleting an SSO provider is immediate and affects all users who relied on it.

What happens at deletion:

The provider and its domain mappings are removed from Recomly immediately. The domains become available for reuse.
The identity provider definition is removed from Cognito.
Recomly user accounts and Cognito user accounts for affected members are not deleted — only the sign-in path is severed.

Impact on users:

Any user whose only sign-in method was the deleted provider is locked out immediately. They have no password and no alternative sign-in path.
Users who also have native password login enabled (see Break Glass Access) can continue to sign in with their password and are unaffected.

If you recreate the provider: Recreating a provider with the same configuration generates a new internal provider identity — Recomly cannot reuse the old one. Existing users' SSO links are orphaned and do not automatically reconnect.

However, access does self-heal: when a previously linked user attempts to sign in via the new provider, Recomly detects their existing account by email address and re-links the new provider to it. The user will see a brief error on their first sign-in attempt and must retry — on the second attempt they are signed in successfully.

This means recreating a provider restores access for all affected users without requiring admin intervention, but it is not seamless. Users should be informed to expect the one-time retry.

Seat limits and provisioning

Neither Google sign-in nor enterprise SSO bypasses seat limits.

Google sign-up (new org) — the account owner does not consume a seat from a plan quota at sign-up time.
Enterprise SSO (existing org) — if your plan's user quota is reached, new members who attempt to sign in via SSO for the first time will be blocked. An admin must free a seat or contact support before new members can access the organization.

Users who already have an account (created by invite or previous sign-in) are never affected by this limit — they can always sign in.

Emergency access

If Google or your identity provider becomes unavailable, users who rely exclusively on those methods will be locked out. Recomly supports designating a break glass account — a specific user with native password login enabled — for emergency access.

See Break Glass Access for requirements and setup instructions.

Single Sign-On Overview

On this page