Deliverd

Identity and single sign-on

Let your team sign in to Deliverd with the accounts they already have, through SAML 2.0 or OpenID Connect. Connecting a provider, proving your email domains, requiring SSO, and what happens to people's existing accounts.

Single sign-on is set up on Admin → Identity & SSO by an owner or admin, and is included in Team, 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
They are added just in time as a viewer. Promote them on Admin → 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. Only an administrator can.

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.

What is recorded

EventWhen
idp.connected, idp.disconnectedAn administrator connects or removes a provider.
idp.domain_verifiedA domain passes its DNS check, from Check now or the automatic re-check.
idp.enforcement_changedSSO is required, or made optional again.
auth.sso_loginSomeone signs in through the provider.
auth.sso_user_provisionedA first-time user is given a membership.
auth.sso_account_linkedAn existing account is linked to the provider's account.
auth.sso_domain_rejectedThe provider vouched for an address outside the connection's domains.
auth.sso_inactive_memberA suspended member signed in and was not reinstated.

All of these appear in the audit log.