Company sign-in

Brokerages sign their people in with their own identity provider. ListOnce operator admins set it up with you, test it, then switch it on.

Rule	What it means
Protocol	OpenID Connect, authorization code flow with PKCE (S256), state and nonce. The ID token's signature is checked against your provider's published keys, with its issuer, audience and expiry.
Who is sent to your provider	Anyone who types an address at one of your domains on the sign-in page, once the connection is on, and gets no emailed link. People at your domains who belong only to other orgs, and ListOnce staff, keep emailed links.
Who gets in	People your provider signs in whose email is at one of your domains and who are members of your org. Invite people from Console, Settings first. Each person is tied to your provider's account id (sub) on first sign in; a different account with the same email is refused later.
Just in time membership	Off unless you ask. When on, anyone your provider signs in at your domains joins as an agent (staff for MLS and licensee orgs), never as an admin.
Two-step	If your provider reports multi-factor sign-in (the ID token's amr claim includes mfa), the session counts as two-step and admin actions work. If not, admins still turn on two-step here and enter its code; others are asked only if they turned it on.
Email	Taken from the ID token's email claim, and only when your provider vouches for it: email_verified true, or for Entra ID the xms_edov claim true. Otherwise sign in is refused.
Your client secret	Stored encrypted (AES-256-GCM) with a key held outside the database, and never shown again.
Domains	Your company's own domains only; shared consumer mail such as gmail.com is refused. A domain belongs to one org.
Turning it off	People at your domains get emailed links again at once. Ask ListOnce to turn it off or change it.

Rule: Protocol
What it means: OpenID Connect, authorization code flow with PKCE (S256), state and nonce. The ID token's signature is checked against your provider's published keys, with its issuer, audience and expiry.

Rule: Who is sent to your provider
What it means: Anyone who types an address at one of your domains on the sign-in page, once the connection is on, and gets no emailed link. People at your domains who belong only to other orgs, and ListOnce staff, keep emailed links.

Rule: Who gets in
What it means: People your provider signs in whose email is at one of your domains and who are members of your org. Invite people from Console, Settings first. Each person is tied to your provider's account id (sub) on first sign in; a different account with the same email is refused later.

Rule: Just in time membership
What it means: Off unless you ask. When on, anyone your provider signs in at your domains joins as an agent (staff for MLS and licensee orgs), never as an admin.

Rule: Two-step
What it means: If your provider reports multi-factor sign-in (the ID token's amr claim includes mfa), the session counts as two-step and admin actions work. If not, admins still turn on two-step here and enter its code; others are asked only if they turned it on.

Rule: Email
What it means: Taken from the ID token's email claim, and only when your provider vouches for it: email_verified true, or for Entra ID the xms_edov claim true. Otherwise sign in is refused.

Rule: Your client secret
What it means: Stored encrypted (AES-256-GCM) with a key held outside the database, and never shown again.

Rule: Domains
What it means: Your company's own domains only; shared consumer mail such as gmail.com is refused. A domain belongs to one org.

Rule: Turning it off
What it means: People at your domains get emailed links again at once. Ask ListOnce to turn it off or change it.

What to send us

Register ListOnce as a web application in your provider with this redirect URI, then send the details below. We run Test connection, which checks discovery, the issuer, signing keys and the client id and secret without signing anyone in. It can be switched on only after every check passes.

Redirect URI

https://listonce.io/api/sso/callback

Details

Issuer URL:      https://...
Client id:       ...
Client secret:   (send through a password manager share, never plain email)
Email domains:   example.com, example.net
Just in time:    on or off

Google Workspace

In Google Cloud console, open APIs and Services. Set the OAuth consent screen to Internal, so only your Workspace accounts can sign in. Under Credentials, create an OAuth client ID of type Web application and add the redirect URI. Issuer: https://accounts.google.com.

Google does not send amr, so admins also use two-step here.

Microsoft Entra ID

In the Entra admin center, open App registrations, New registration. Choose accounts in this organizational directory only and add the redirect URI as a Web platform. Under Certificates and secrets, add a client secret and copy its value. Under Token configuration, add the optional claims email and xms_edov to the ID token: Entra leaves email out by default and never sends email_verified, so xms_edov (your domain is verified in the tenant) is what lets the email count. Issuer: https://login.microsoftonline.com/<tenant id>/v2.0.

Entra does not always send amr in ID tokens. If the token has no amr listing mfa, admins also use two-step here.

Okta

In the Okta Admin Console, open Applications, Create App Integration, choose OIDC and Web Application. Add the redirect URI as a sign-in redirect URI, keep client authentication as client secret, and assign the people or groups who should sign in. Issuer: https://<your okta domain>, or https://<your okta domain>/oauth2/default if you use a custom authorization server.

With an MFA sign-on policy, Okta reports it in amr.

Not included yet

SAML is planned and not available; providers that offer OpenID Connect work today. Automatic user provisioning and removal (SCIM) is not included: remove people in Console, Settings, as well as in your provider.