Identity and single sign-on

Single sign-on is set up on Organisation → Identity & SSO by an owner or admin, and is included in Team, Business Starter, Business and Enterprise. You connect your identity provider, name the email domains it covers, prove you own those domains, and then — when you are ready — require it.

Choose a provider#

Microsoft Entra ID, Okta, Other SAML 2.0 provider

SAML connections configured from the provider's metadata URL.

Google Workspace

A SAML connection through a custom SAML app. Google exports metadata as a file, so you paste the metadata XML instead of a URL.

OpenID Connect

One connection for any provider that speaks OpenID Connect — Google, Okta, Entra, Auth0, Keycloak, Ping. You give its issuer URL, and the rest is read from the provider.

Connect with SAML#

1. 1

   Give your provider our details

   On your provider's card, open What to enter in … and copy the Entity ID, ACS URL, Metadata address and NameID format into a new SAML application at your provider. The NameID must be the email address or a persistent identifier, and the assertion should carry the person's email (and ideally their name).

2. 2

   Give us your provider's metadata

   Paste your provider's metadata URL — or, for Google Workspace, the contents of its metadata file.

3. 3

   List your email domains

   The domains whose people should sign in through this provider, separated by commas.

4. 4

   Connect

   The card shows Connected once the connection is registered. If something is wrong, the reason is shown on the card.

Connect with OpenID Connect#

1. 1

   Register an application at your provider

   Use the Redirect URI shown at the top of the OpenID Connect form, exactly as shown. It must be a confidential client — one with a client secret — and request the openid, email and profile scopes.

2. 2

   Fill in the form

   The provider's Issuer URL, the application's Client ID and Client secret, and your Email domains. The secret is encrypted before it is stored and never shown again.

3. 3

   Save

   Saving checks the issuer with the provider there and then, and refuses if it cannot be reached or describes a different issuer — so a typing mistake is caught now, not at someone's first sign-in.

At sign-in, the provider must vouch for an email address that is present, marked verified, and on one of the connection's domains.

Prove your domains#

A domain routes sign-in only after you prove you own it. For each domain the connection lists, the card shows a DNS TXT record to publish at _deliverd-verify. followed by the domain. Add it with your DNS provider, then choose Check now; unverified domains are also checked again automatically. When the check passes, the domain shows Routing.

• Until a domain is verified, people at that domain keep signing in with a password or an email link. Nobody is locked out while you set up.
• A domain can belong to only one connection across the whole platform.
• Public mailbox domains, such as gmail.com or outlook.com, cannot be claimed.

How people sign in#

On the sign-in page, people choose Company and enter their work email. The domain decides which provider they are sent to. Once someone has signed in through the provider for the first time, they are a member of your organisation:

New to your organisation

What happens depends on Account management on Directory Sync. Until you choose, they are added just in time as a viewer — the default, unchanged since SSO first shipped. With Deliverd invitations they need an invitation first; with Enterprise directory they need to have been provisioned by your directory. Promote people on Organisation → People if they need to publish or administer.

Already a member

Their identity-provider sign-in arrives as a new account, and Deliverd links it to the one they had: their memberships and roles, groups, the reports they own, what was shared with them, their comments and notifications move across. The audit log is not rewritten — past events stay with the original account, and an auth.sso_account_linked event records the link.

Suspended

Signing in through the provider does not reinstate them, and they are told their access is suspended rather than let in to an empty console. Only an administrator can reinstate them — or your directory, if it was the directory that suspended them.

People are matched on the identity your provider gives them, not only their address. For Microsoft Entra that is the tenant and the person's object ID, so somebody whose address changes keeps their account, and somebody given a former colleague's address does not inherit that colleague's account. You can also pin your Entra tenant ID on Directory Sync: a sign-in from any other tenant is then refused.

Require SSO#

Once a connection is working, turn on Require SSO on its card. Passwords and email links then stop working for its domains, and anyone who tries one is sent to the Company tab instead.

• It cannot be turned on for a connection that is not live, or that has no domains — either would leave people with no way in.
• Turn it off again on the same card; passwords and email links work again straight away.
• Disconnecting a provider returns its members to passwords and email links.
• Slack approval buttons stop working for its domains. Teams buttons keep working for people a Microsoft Entra ID connection over OpenID Connect has signed in: Teams proves they are the same Microsoft account, in the connection's tenant and your pinned tenant if you set one, and that is checked again on every press. A SAML sign-in does not record the Entra object ID, so people who sign in over SAML decide on the page.

What is recorded#

All of these appear in the audit log.