Single sign-on (SSO)

A workspace on the Business plan can let its people sign in with the organisation's own identity provider (IdP) over OpenID Connect or SAML 2.0: Okta, Microsoft Entra ID, Google Workspace, Keycloak, Auth0, JumpCloud, OneLogin, ADFS and any other provider that speaks either. Choose OpenID Connect when your IdP offers both; it's simpler to set up. It's optional. Everyone's other ways in (a password, Google, Microsoft) keep working.

Single sign-on is set up by an Owner in Org Settings → Security. Admins can see the setup but not change it. On a phone you can look; setting it up is done on a computer.

How people sign in

1. On the sign-in page they choose Sign in with SSO and type their work email.
2. If the address is on one of the workspace's verified domains and single sign-on is switched on, Missived sends them to the IdP. (We never say whether an account exists for the address.)
3. They sign in there and come back signed in to Missived. Missived doesn't ask for its own second factor after the IdP: the IdP's sign-in, with whatever factors you require there, is the check.

The first time, one of three things happens:

Missived never links an account just because the email address matches. The IdP's account is tied to its own stable subject (OpenID Connect's sub, SAML's name ID), not the address, so a changed address at the IdP still reaches the same Missived account.

Someone whose address isn't on a verified domain can still use single sign-on if they're already a member and confirm their account as above; new people from other domains can't join that way. Leaving the workspace, or being removed from it, removes the person's link, so coming back through single sign-on means confirming the account again.

Setting it up

1. Make an application in your IdP

First choose OpenID Connect or SAML 2.0 in Org Settings → Security. For SAML, see SAML 2.0 below; the steps after this one are the same for both.

Make a web application (OpenID Connect, authorization code) with:

• Redirect URI: the one shown in Org Settings → Security (for missived.com, https://app.missived.com/auth/sso/callback).
• Scopes: openid email profile. Missived asks for nothing else.
• Who may use it: the people or groups who should reach this workspace. Missived only trusts what your IdP says.

Note the issuer URL, the client ID and a client secret.

2. Enter the details

In Org Settings → Security, fill in a name people will recognise (like "Acme Okta"), the issuer URL, the client ID and the client secret, and choose how the secret is sent (client_secret_post by default, or client_secret_basic). When you save, Missived reads the issuer's discovery document and refuses an issuer that doesn't name itself exactly as you typed it.

The secret is stored encrypted and never shown again. To change it, paste a new one; leave the field empty to keep it.

3. Test, then switch on

Choose Test sign-in. You sign in at your IdP and come back to a page showing the email, name and subject it sent. Nobody is signed in by a test. Once a test has passed, Switch on. Changing the issuer or client ID later puts single sign-on back to "not switched on" until a new test passes.

4. Verify your email domain

Add your domain (for example acme.com) and publish the TXT record it shows, at the domain itself or at _missived.<domain>:

missived-domain-verification=<token>

Then choose Check now. DNS can take a while. A verified domain lets people find your sign-in from their address, and lets new people on the domain get an account. A domain can be verified by only one workspace. Public mail domains (Gmail, Outlook.com and the like) can't be added.

5. Choose the settings

• Make an account the first time someone signs in (on by default): only for verified domains.
• New people join as Members, never Admin or Owner. (Guests are invited into a category as usual.)
• Stay signed in for: 1 to 30 days (7 by default). After that, people sign in with your IdP again.

SAML 2.0

Choose SAML 2.0, give the connection a name and save. Missived then shows the three values your IdP asks for:

In your IdP, make a SAML application with those, and set:

• Name ID: a persistent identifier (or the email address). A transient name ID changes every time and is refused.
• An email attribute (or mail, or the standard emailaddress claim), unless the name ID is the email. A display name (displayName, or first and last name) is used when present.
• Signing: sign the response or the assertion (or both) with SHA-256 or stronger. SHA-1 is refused. Encrypted assertions aren't supported yet.

Then give Missived your IdP's side: paste its metadata XML, give its metadata URL (read once when you save), or type the entity ID, the sign-in URL (HTTP-Redirect binding) and the signing certificate. Missived trusts only the certificates from that metadata, never one sent inside a response. To roll a certificate, give the metadata again with both certificates in it; a different IdP or certificate puts single sign-on back to "not switched on" until a new test passes. Org Settings shows each certificate's fingerprint and when it expires.

Missived checks every response: signed by your IdP's certificate, for this connection (audience, destination and recipient), from your IdP (issuer), answering a sign-in that started on Missived in the last ten minutes, within a minute of the right time, and used only once. Sign-ins must start on Missived (Sign in with SSO): starting from the IdP's own app list isn't accepted yet.

Who signs in with it

The People who sign in with it list shows who has linked their account and when they last signed in. An Owner can remove someone's link: they keep their account and its other ways in, and the next time they use single sign-on they confirm their account again. Leaving or being removed from the workspace removes the link too. Removing single sign-on altogether removes every link; accounts and messages stay.

An Owner can also Sign out someone: every session they started with single sign-on ends at once. Missived doesn't receive word from your IdP when it disables someone (that comes with SCIM, later), so use this when a person leaves before their session would run out.

Requiring it

By default single sign-on is optional: people may use it or their other ways in. An Owner can make it required in Org Settings → Security → Require single sign-on. It applies to members whose account address is on one of your verified domains:

• Their password, Continue with Google and Continue with Microsoft stop working for that account. They're told "<Workspace> signs you in with its own sign-in. Use Sign in with SSO.", only after the password itself was right.
• When you switch it on, their sessions that didn't come from your single sign-on end, and each of them gets an email saying how to sign in from now on.
• A session that came from your single sign-on is re-checked every time it refreshes: if the person's link was removed, they left the workspace, or single sign-on was switched off, it ends.

Owners are never required to use it, and neither are Guests or members whose address is on another domain. That's on purpose: if your IdP is down or misconfigured, an Owner signs in with their password and second factor and makes it optional again. So before you can require it:

• single sign-on must be on, after a test sign-in that worked;
• at least one domain must be verified;
• at least one Owner must have a password and a second factor;
• you confirm with your password (and your second factor, if you have one).

Making it optional again always works, even after the workspace has moved to a plan without single sign-on, and needs no confirmation code.

Switching the connection off, removing it, or pointing it at a different IdP (which puts it back to draft until a new test passes) makes single sign-on optional again too, so nobody is locked out meanwhile. Switching it back on doesn't require it again: an Owner chooses that afresh, with the same checks.

Keeping domains verified

Missived re-checks each verified domain's TXT record about once a day. If the record is missing on three checks in a row, the domain is no longer verified: requiring single sign-on stops applying to its addresses, they can't find your sign-in from their address, and new people can't join through it. Every Owner gets an email. Put the record back and choose Check now. A DNS outage (no answer at all) never counts against a domain.

Plans

Single sign-on is the sso switch in Plans and availability. If a workspace moves off a plan that includes it, people already linked keep signing in, and an Owner can still see, switch off and remove the setup, but nothing new can be set up and new people can't join through it. Requiring it stops at once: members get their other ways in back.

Privacy

Missived talks to your IdP from our servers only to read its discovery document and keys and to trade the sign-in code (OpenID Connect), or to read its SAML metadata once when you give a metadata URL. A SAML sign-in reaches us from your IdP through the person's browser. We store the IdP's subject and email for each linked person, the client secret (encrypted), and an audit line for each sign-in, link and change (never the code or tokens). A short-lived cookie, mv_sso, holds the sign-in round trip together for ten minutes and is removed when you come back. For SAML we also keep each assertion's id until it could no longer be used, so it can't be used twice.

Not yet

IdP-initiated SAML sign-in, encrypted SAML assertions, single logout and SCIM provisioning are planned. See the roadmap.