Skip to main content
Enterprise SSO lets the members of your organization sign in to Modem through your company identity provider instead of GitHub or Google. Modem supports SAML 2.0 and OIDC, and has step-by-step guides for Okta, Microsoft Entra ID, and Google Workspace. To also create and remove Modem accounts automatically from the same directory, see Directory Sync.
Enterprise SSO requires the Enterprise plan and is turned on per organization by Modem. Contact support@modem.dev to have it enabled before you start.

​
Requirements

  • The Enterprise plan, with SSO enabled for your organization by Modem
  • The owner role in the Modem organization. Admins and members can open the SSO settings page but cannot change anything
  • One identity provider per organization: either SAML 2.0 or OIDC, not both
  • Access to DNS for the email domain you want to claim, so the domain can be verified

​
How it works

Setting up SSO is a round trip between your identity provider and Modem, because each side needs a value the other one generates.
1

Create the application in your identity provider

Create a SAML app (Okta, Entra) or an OIDC client (Google Workspace) and point it at Modem’s ACS URL or redirect URI. A SAML app also wants an audience or entity id, which Modem hasn’t issued yet, so put a placeholder there on this first pass. An OIDC client needs nothing back from Modem, so its setup is a single pass.
2

Register the provider in Modem

Go to Settings → SSO in the Modem dashboard and enter the values your identity provider gave you: the issuer, the sign-on URL, and the signing certificate for SAML, or the issuer, client id, and client secret for OIDC.
3

Paste Modem's values back into the application

Once the provider is registered, the SSO settings page shows the values Modem generates — the SP entity ID, the ACS URL, the SP metadata URL, and the OIDC redirect URI. Copy the ones your provider needs back into the app you created in step 1.
4

Verify your email domain

Publish the DNS record Modem shows you and click verify. See Domain verification below. Sign-in is refused until this succeeds.
5

Test the sign-in

Sign out, go to https://app.modem.dev, and click Continue with SSO. See Signing in below.

​
The values you exchange

Modem generates the values in this table from your organization’s numeric id. Copy them from the SSO settings page rather than building them by hand — the page shows the exact strings for your organization. In each of these, <id> is your Modem organization’s numeric id and org- is literal. Going the other way, Modem needs these from your identity provider:
Modem’s SP Entity ID (Audience URI) is the same value you entered as your identity provider’s Entity ID / Issuer, so it will look like your IdP’s own issuer URL. That is expected. Copy it exactly as Modem shows it, and replace the placeholder audience in your IdP app with it.

​
Domain verification

Before anyone can sign in, your organization has to prove it controls the email domain it is claiming, for example acme.com.
1

Get the token

Modem issues a verification token on the SSO settings page. The token is stable — requesting it again returns the same value rather than rotating it — and it expires after 7 days if it is never used.
2

Publish a DNS TXT record

Create a TXT record at _modem-verification-org-<id>.<domain>, where <domain> is the domain you are claiming. The value is the bare token, with no prefix and no quoting beyond whatever your DNS provider adds itself.
3

Verify in Modem

Click verify on the SSO settings page. DNS propagation can take anywhere from a few minutes to a few hours, so if verification fails the first time, wait and retry — there is no penalty for retrying.
Until the domain is verified, Continue with SSO refuses the sign-in with “Single sign-on is not finished being set up”, even though the provider is fully configured on both sides.

​
Signing in

Users go to https://app.modem.dev and click Continue with SSO, then type either their work email address or your Modem organization slug. Modem resolves the provider from the email domain (or from the slug) and sends them to your identity provider. When they come back, they are signed in. What happens on the Modem side depends on the person: The owner role is never granted automatically. Promote someone from Settings → Team; see Team Management for what each role can do.
SSO is an additional way in, not yet a required one. GitHub and Google sign-in still work for the same users. Enforcing SSO is planned for a later release.

​
Identity attributes

Modem stores one stable identifier per user, taken from your identity provider. Choosing the right one matters more than it looks, because Directory Sync matches directory users to Modem users by externalId — and externalId has to be the same value as the SSO identifier.
Never use email as the identifier. People change email addresses, and matching on email is how one person’s account ends up handed to someone else. Use the immutable directory id below for your provider.
For SAML, Modem reads the rest of the profile from the assertion like this: So every SAML app should send a NameID set to the stable immutable id, plus an attribute statement carrying email, givenName, and surname.

​
Limitations

  • SP-initiated sign-in only. Users must start from the Modem sign-in page. IdP-initiated sign-in — the Okta dashboard tile, the Entra “My Apps” tile — is not supported and is rejected.
  • Assertions must be signed. Modem rejects unsigned SAML assertions. Signing the whole response as well is fine but not required.
  • Encrypted assertions are not supported.
  • Assertions are single-use. Each one may be consumed once, and must be consumed within a few minutes of being issued.
  • One provider per organization, either SAML 2.0 or OIDC.
  • SSO is not yet required — GitHub and Google sign-in remain available.
  • No single logout (SLO). Signing out of Modem does not sign the user out of your identity provider, or the reverse.

​
Troubleshooting

The email domain typed at Continue with SSO has no provider registered against it. Check that the domain on the SSO settings page matches the domain in the address, and that the person is using their work address rather than a personal one.
The provider exists but the domain has not been verified. Publish the DNS TXT record and verify, as described in Domain verification.
Someone launched Modem from a tile in your identity provider’s dashboard. Modem only accepts SP-initiated sign-in, so send them to https://app.modem.dev and have them click Continue with SSO instead.
Check that your identity provider is signing the assertion, that the certificate registered in Modem is the current one, and that the Audience URI in the app matches the SP Entity ID Modem shows. A certificate rolled in the IdP has to be re-entered in Modem.
Roles come from Modem, not from your identity provider. A first-time user joins as a member unless they had a pending invitation carrying a different role. Change roles in Settings → Team.

​
Set up your provider

Okta

SAML 2.0 app integration, with the Okta user id as the NameID.

Microsoft Entra ID

SAML enterprise application, with the directory object id as the NameID.

Google Workspace

OIDC client, using Google’s stable sub claim.

Team Management

Roles, invitations, and auto-join.