How does e-mail discovery work at login?

Requires Pro

Short answer

As soon as someone enters their email address on the login screen, Notory checks in the background whether SSO is available for exactly this address. If so, the “Sign in with …” button for the matching provider appears automatically. What matters is the exact address — not the domain: Notory looks up which tenant the account belongs to and shows that tenant’s enabled OIDC providers.

Requirements

The account must already exist: discovery finds the tenant via the user account tied to that e-mail. For brand-new users, the screen therefore shows no SSO button (details under “What happens behind the scenes?”).

Enter the e-mail. On the login screen, type in the email address and leave the field. Notory checks in the background whether SSO is available for this account.
The SSO button appears. If an enabled OIDC provider is configured for the account’s tenant, the screen shows “Sign in with <Provider>”. Clicking it starts the login at the identity provider; the password field remains visible as an alternative.

Screenshot pending admin-sso-03 Login screen with the e-mail entered and the 'Sign in with' button for the SSO provider automatically shown

E-mail discovery: after entering the address, the matching SSO button appears automatically.

Discovery is a public endpoint (no authentication — it runs before login, after all):

curl -X POST https://demo.notory.io/api/v1/auth/sso/discover \
  -H "Content-Type: application/json" \
  -d '{ "email": "lena.vogt@acme.example" }'

{
  "providers": [
    {
      "id": "018f9d22-3c4d-7e55-9f60-7a8b9c0d1e2f",
      "provider_name": "Firmen-Login (Entra ID)",
      "protocol": "oidc",
      "start_url": "/api/v1/auth/sso/018f9d22-3c4d-7e55-9f60-7a8b9c0d1e2f/start"
    }
  ]
}

If there’s no account for that address — or no enabled OIDC provider in the tenant — the response is simply { "providers": [] } (deliberately without an error message). The actual login then starts with a GET on the start_url, which redirects to the IdP’s authorization page.

What happens behind the scenes?

Exact address instead of domain (home realm discovery). Notory looks up the user account for the exact e-mail and returns the enabled OIDC providers of its tenant. This lets two mailboxes on the same domain (e.g. a@company.com at tenant A, b@company.com at tenant B) belong to different tenants with different IdPs without any conflict — a domain-based mapping wouldn’t have a unique answer here.
No account enumeration with any real value. The response only reveals whether SSO is offered — for unknown addresses it’s empty and indistinguishable from “account without SSO”. Password sign-in remains possible independently of this.
Consequence for new users: since discovery requires an existing account, brand-new users without an account see no SSO button. Common approaches: the administrator creates the account beforehand (creating a user) — after which discovery kicks in — or they share the provider’s direct SSO start link, through which, with JIT provisioning enabled, the account is created automatically at first login.
Only enabled OIDC providers. Disabled providers and pure SAML entries do not appear in discovery.