Enterprise SSO

Enterprise SSO lets your team sign in to DevStride through your organization's own identity provider — Microsoft Entra ID, Okta, Google Workspace, or anything that speaks OIDC or SAML 2.0.

This page is the full setup path, in the order you actually have to do it:

1. Register DevStride in your identity provider
2. Add the provider in DevStride
3. Verify your email domain
4. Confirm SSO works
5. Turn on automatic member provisioning (optional)

Before you start

Permission. Managing identity providers requires the Manage Identity Providers permission, which Owner and Admin both have by default. You can also grant it to a custom role.

Where to find it. In the left sidebar, select Configure Settings, open the Integrations section, and choose Identity Providers.

What you'll need:

• Owner or Admin in DevStride, or a custom role with Manage Identity Providers.
• Administrative access to your identity provider, so you can create an app registration.
• Access to your domain's DNS, so you can publish a TXT record.
• Your organization's email domain (for example acme.com).

Step 1: Register DevStride in your identity provider

Registering is a two-way exchange: DevStride needs credentials that only exist once you've created the app registration, and your identity provider needs one or two values that only DevStride can give you. So both paths below start in DevStride, collect what you need, and return there to finish.

If you're using OIDC

DevStride gives you one value, from the Give these to your provider panel on the Identity Providers page; you bring back three.

Next, go and create the application. Microsoft Entra and Okta: exact steps — which screen to open, what to paste, and where each value below is found. Using a different provider? Create a web/OIDC application, set the Redirect URI above on it, and collect these three:

For Microsoft Entra, the issuer must name your tenant by GUID:

https://login.microsoftonline.com/<your-tenant-guid>/v2.0

If you're using SAML 2.0

DevStride gives you two values, from the Give these to your provider panel on the Identity Providers page; you bring back your provider's metadata.

Next, go and create the application. Microsoft Entra and Okta: exact steps — which screen to open, where to paste the two values above, and where to find the metadata.

Using a different provider? Create a SAML 2.0 application, paste both values above into it, then export its metadata — either a metadata URL or the metadata XML document — to bring back to DevStride.

Where these values live in your identity provider

This is the step-by-step for creating the application — which screen to open, what to paste where, and where to find every value DevStride asks for. DevStride can't show you these: they belong to your tenant.

Find your provider below, work through it, then return to Step 2.

Microsoft Entra ID

OIDC — in the Entra admin center, open Entra ID → App registrations in the left sidebar, then select New registration. Microsoft's own walkthrough: Register an application.

SAML — in the Entra admin center, open Entra ID → Enterprise apps in the left sidebar, then:

1. New application → Create your own application.
2. Name it — this is Entra's own label for the app, so anything you'll recognize works. DevStride is a good default. Entra may suggest similar-looking gallery apps as you type; ignore them, none of them are DevStride.
3. Leave Integrate any other application you don't find in the gallery (Non-gallery) selected — it already is — and select Create.
4. In the app that opens, go to Single sign-on and choose SAML. Microsoft's walkthrough: Set up SSO for an application.

Both fields show a green tick when the value is accepted, and Save stays greyed out until then. Select Save before closing the panel — you should see "Single sign-on configuration was saved successfully."

Okta

OIDC — Applications → Create App Integration → OIDC / Web Application.

SAML — Applications → Create App Integration → SAML 2.0.

Step 2: Add the provider in DevStride

1. Go to Configure Settings → Integrations → Identity Providers.
2. Select Add Identity Provider.
3. Fill in the dialog:

4. Select Create.

The provider is created and registered with the sign-in platform immediately — there's no waiting period. When the Status column reads active, the configuration is live.

If the status comes back failed, waiting won't help — the configuration was rejected. Fix the details with Edit, then select Resync.

Step 3: Verify your email domain

DevStride requires proof that your organization controls a domain before it will route that domain's sign-ins to you.

1. Next to the unverified domain, select Verify.
2. DevStride shows the Name and Value for a DNS TXT record. Copy both from that panel — the value is unique to this claim, and it changes if you ever delete and re-create the provider.
   For acme.com the name is _devstride-challenge.acme.com, and the value looks like devstride-domain-verification= followed by a 64-character token.
3. Add that TXT record with your DNS provider — see below.
4. Come back to DevStride and select Check DNS.

_devstride-challenge

The dedicated _devstride-challenge name keeps the record clear of your SPF, DMARC, and other TXT records at the domain root, so you can add and remove it without touching mail configuration. Other TXT records at the same name are ignored — so if an older DevStride token is still published, you can safely leave it while adding the new one.

When the record is found, the domain is marked verified and starts routing sign-ins immediately.

A few things worth knowing about domains:

• You can remove the TXT record once the domain is verified. DevStride never re-reads it, and a verified domain can't be lost to a later DNS blip. Keep it only if you'd rather not think about it.
• Verification is what claims a domain. Several organizations may hold an unverified claim on the same domain, but only one can hold a verified one — the first to prove control takes it, and nobody can lock you out of your own domain by claiming it first.
• Subdomains are separate. A claim on acme.com does not cover mail.acme.com. Each needs its own claim and its own TXT record.
• Verified domains can't be removed by editing the provider. Releasing one means deleting the provider.

Confirm SSO works before you tell your team

Do this yourself, first, on your own account. It takes a minute and it is the difference between "I think it's configured" and "I know it works".

1. Go to your DevStride sign-in page in a private window.
2. Type your work email address in the Username or Email field.
3. Select Sign in with SSO.

What should happen: you're sent to your identity provider, sign in there, and land back in DevStride. If your provider already has a live session you may not be prompted for anything — that's normal, not a bypass.

If it fails, the message tells you where to look:

Only once your own sign-in works should you point the rest of your team at it — see How your team signs in.

Step 4 (optional): Turn on automatic member provisioning

Automatic provisioning — sometimes called JIT — lets someone from your company who was never invited sign in through SSO and get a DevStride account created on the spot.

1. Select Edit on the provider.
2. Under Member Provisioning, turn on Automatically create members on first sign-in.
3. Choose a Role for new members.
4. Select Save.

If you leave the role blank, DevStride uses your organization's default invite role. If you have no default invite role either, you must pick a role here — provisioning refuses to guess rather than create a member with no permissions.

The Owner role is never offered as a provisioning role.

Provisioning is bound to your verified domains: an account is only ever created for an email address on a domain this provider has proven it controls. It can never create accounts on another organization's domain.

How your team signs in

The DevStride login page always shows a Sign in with SSO button, below the password field and the Google and Microsoft buttons. It's always there — it doesn't appear or disappear as you type, and it looks the same for everyone.

For a member signing in:

1. Type your work email address in the Username or Email field.
2. Select Sign in with SSO.
3. DevStride looks up your email domain, sends you to your company's login, and brings you back signed in.

Messages a member might see on the login page:

Messages after being sent back from your identity provider:

Requiring single sign-on

By default SSO is an additional sign-in method. You can also make it the only one: turn on Login policy → Require single sign-on on the same Identity Providers page.

Once it's on, password and social sign-in are refused for everyone in your organization. Members see a plain message telling them to use SSO — not a generic error.

What to expect when you turn it on:

• It is not an immediate sign-out. Members who are already signed in stay signed in until their next token refresh, then come back through SSO.
• You need a working provider first. The toggle stays disabled until you have an active identity provider with a verified domain. This is deliberate — it's what stops you switching off every other way in before the replacement works.
• DevStride confirms before applying it, because the blast radius is the whole organization.

Guardrails DevStride enforces for you:

• You cannot require SSO without a ready provider (the toggle is disabled).
• You cannot delete your last working identity provider while SSO is required — the deletion is refused, not merely discouraged. See Removing an identity provider.

SSO and multi-factor authentication

If your organization has Require multi-factor authentication turned on, SSO sign-in is refused for that organization. It isn't bypassed and it isn't satisfied — it's blocked.

The reason is that federated sign-ins don't pass through DevStride's MFA challenge. An organization that mandates MFA and also permits federated sign-in would have that guarantee quietly voided, so DevStride refuses the combination outright.

If you want SSO, enforce multi-factor authentication at your identity provider instead — which is generally where enterprises want it anyway, since it applies across every application your team signs in to, not just DevStride.

Keeping a provider working

The Identity Providers list shows each provider's Status, Claimed Domains, and Last Synced time.

Status values:

Resync re-registers the provider with the sign-in platform using its current configuration. Use it when a provider shows failed, or after you've corrected settings on the IdP side. It's safe to run at any time.

Removing an identity provider

There's no disable switch — Delete is the only way to stop a provider.

1. Select Delete on the provider row.
2. Confirm: Delete name and release its claimed email domains? This cannot be undone.

What happens:

• SSO stops immediately. The next attempt to sign in through it fails.
• Claimed domains are released, including verified ones. Another organization can then claim and verify them.
• Member accounts are not touched. Nobody is deleted or deactivated, and everyone keeps their work, roles, and memberships.
• Members fall back to other sign-in methods. Anyone whose account was created through SSO has no password yet, so they'll need to use I forgot my password to set one.

What Enterprise SSO does not do

• It does not deprovision members. When someone is removed from your identity provider, they can no longer complete an SSO sign-in — but their DevStride account and membership remain active. There is no SCIM or directory sync. Remove departing members from DevStride yourself, under Settings → Organization → Users.
• It does not force SSO by default. Out of the box, members with a password can still use it. If you want SSO to be mandatory, turn on Require single sign-on — it is opt-in, and off until you choose it.
• It does not replace personal Microsoft or Google sign-in. The Sign in with Microsoft button serves personal accounts (outlook.com, hotmail.com, live.com). Company work accounts in your Entra tenant go through Enterprise SSO. See Users, Roles & MFA.

Troubleshooting