Authentication Flow

The authentication journey a user experiences depends on the login method they choose and the SSO policies configured for their organization. This page explains how Seal evaluates each login attempt, routes users to the correct identity provider when required, and links multiple authentication methods to a single user record.

Home Realm Discovery

Home Realm Discovery (HRD) is the mechanism Seal uses to determine whether a user should be routed to their organization’s SSO identity provider (IdP).

When a user enters their email address, Seal extracts the email domain and checks whether it matches a verified domain on any organization in the environment. If a match is found and the organization has an enabled, published SSO connection, Seal redirects the user to that organization’s IdP instead of proceeding with password or magic link authentication.

For example, if Acme Corp registers and verifies acmecorp.com as an organization domain and configures an SSO connection with Okta:

jane@acmecorp.com signs in — Seal detects the domain match and redirects Jane to Okta
alex@gmail.com signs in — no domain match, so Alex proceeds with the standard login methods

HRD requires two conditions to trigger:

The email domain matches a verified organization domain
The organization has an SSO connection that is enabled and in Published status

HRD applies to all login methods, but the timing differs depending on the method.

HRD runs before authentication. When the user enters their email address, Seal checks for a domain match immediately. If a match is found, the user is redirected to SSO without entering a password or receiving a verification code.

HRD runs after the social provider returns the user’s profile. When a user authenticates with Google or Microsoft, Seal receives their email address from the provider and checks whether the domain matches an organization with an active SSO connection. If a match is found, Seal redirects the user to the organization’s IdP instead of completing authentication — the social login effectively acts as an email identification step.

This ensures that employees cannot bypass their organization’s SSO policy by choosing a social login option. For example, if Acme Corp enforces SSO via Okta, an employee who clicks “Sign in with Google” as jane@acmecorp.com will be redirected to Okta after the Google OAuth step completes.

Authentication flow diagram

Email verification and trust

Seal verifies email ownership differently depending on the authentication method.

Trusted sources

The following authentication methods automatically mark the user’s email as verified:

Enterprise SSO (SAML/OIDC): Email is trusted because the organization’s IT admin controls the IdP and has verified their domain in Seal.
OAuth social login: Email is trusted based on the OAuth provider’s own verification status (for example, Google confirms that the user owns their Gmail address).

Untrusted sources

When a user signs up with password or magic link authentication, their email is not yet verified. Seal sends a verification code to the user’s email address. The user must enter this code to prove inbox ownership before authentication completes.

Authentication method	Email trusted?	Verification required?
Enterprise SSO	Yes	No
Google / Microsoft OAuth	Yes (if provider verified)	No
Password signup	No	Yes — email verification code
Magic link	No (on first use)	Yes — email verification code

Account linking

Seal maintains a single user record per email address within an organization. When a user authenticates with a new method (for example, signing in with Google after previously using a password), Seal links the new identity to the existing user record rather than creating a duplicate.

Each identity is stored as a separate record tied to the user, tracking:

The identity provider (Google, Microsoft, Okta, etc.)
The external user ID from that provider
The email address and its verification status

This design prevents duplicate accounts when users switch between authentication methods and preserves a unified view of each user across all sign-in options.

IdP-initiated SSO

In addition to the standard flow where the user starts at your application, Seal supports IdP-initiated SSO. In this flow, the user starts at their identity provider (for example, clicking the app tile in Okta’s dashboard) and is redirected to Seal’s Assertion Consumer Service (ACS) endpoint.

Seal processes the SAML response, maps attributes, and completes authentication using the same trust and account linking rules as the standard flow. The user is redirected to the default redirect URI configured for the environment.

Next steps

Enterprise SSO — set up SAML or OIDC connections for your customers
Magic Link authentication — enable passwordless sign-in with email verification codes
Social Login — let users sign in with Google or Microsoft
Organizations — manage tenants and domain routing