Enterprise SSO

Enterprise SSO lets your team sign in to DevStride with their company account through Microsoft Entra ID, Okta, or another compatible identity provider.

The setup follows a simple pattern: exchange settings → verify your domain → test sign-in → roll out. You'll work in DevStride, your identity provider's admin portal, and your domain's DNS settings:

1. Connect the two systems. Copy DevStride's connection details into your identity provider, then collect the settings it gives you in return. Choose one protocol: OIDC or SAML.
2. Save the provider in DevStride. Paste those settings into a new identity provider.
3. Verify your email domain. Add a DNS TXT record to prove ownership. This enables SSO routing for that domain.
4. Test sign-in. Use an existing member's account in a private browser window before inviting the rest of the team to use SSO.
5. Choose your rollout options. Optionally create members on their first SSO sign-in or require everyone to use SSO.

Using Microsoft Entra? Start with the prerequisites below, then follow the Microsoft Entra ID walkthrough. It tells you what to copy in each direction and when to return to DevStride.

Before you start

Have these ready:

• DevStride access: Owner, Admin, or a custom role with Manage Identity Providers.
• Identity provider access: permission to create and configure an application and manage its users. For Entra, a Cloud Application Administrator or Application Administrator can handle the setup; someone authorized to grant consent may also be needed.
• DNS access: permission to add a TXT record for your company's email domain, such as acme.com.
• A test member: an active DevStride member whose email matches the email your identity provider will send. Accept any pending DevStride invitation first.

In DevStride, open Configure Settings → Integrations → Identity Providers. Keep this page open in one tab and your identity provider's admin portal in another.

Step 1: Register DevStride in your identity provider

Start in DevStride. The Give these to your provider panel on the Identity Providers page contains the connection details to copy into your identity provider. These values belong to the DevStride environment you are using, so copy them from the product.

Choose one protocol. OIDC is recommended for a new Entra or Okta connection. Use SAML if your organization requires it. The protocol cannot be changed after you create a provider in DevStride.

If you're using OIDC

OIDC (OpenID Connect) uses a redirect address and application credentials:

Follow the Entra OIDC steps or Okta instructions. For another provider, create a web/OIDC application and use its tenant-specific issuer.

If you're using SAML 2.0

SAML uses two DevStride values and a metadata document describing your identity provider:

Follow the Entra SAML steps or Okta instructions. For another provider, create a SAML application with the values above and export its metadata.

Where these values live in your identity provider

Complete the instructions for your provider and chosen protocol, then continue to Step 2.

Microsoft Entra ID

Your route through setup: copy DevStride's values → configure an Entra application → allow your test user access → bring Entra's settings back to DevStride → verify DNS → test sign-in.

Open the Entra admin center and confirm you are in your organization's correct tenant (its Entra directory). If a menu is hard to find, search for App registrations or Enterprise apps using the portal's search bar.

Choose one path:

For OIDC, an app registration also creates an enterprise application in the same tenant. You configure credentials in App registrations and user access in Enterprise apps. For SAML, work in Enterprise apps throughout.

Entra OIDC (recommended)

1. Copy DevStride's Redirect URI. In DevStride, open Configure Settings → Integrations → Identity Providers and copy Redirect URI from Give these to your provider.
2. Register the application in Entra. Open Entra ID → App registrations → New registration. Name it DevStride. Under Supported account types, choose the single-tenant option for your directory. Depending on the portal version, this is labeled Single tenant only or Accounts in this organizational directory only. Select Register. Microsoft's registration guide.
3. Add the redirect address. In the registration, open Authentication → Redirect URI configuration → Add Redirect URI, choose Web, paste DevStride's Redirect URI, and select Configure. Older portal layouts use Authentication → Add a platform → Web. If you already entered a Web redirect URI during registration, check it matches instead of adding it again. Microsoft's redirect URI guide.
4. Collect the IDs. On Overview, copy Application (client) ID for DevStride's Client ID. Copy Directory (tenant) ID and insert it into the issuer URL below. Use the tenant GUID, including its hyphens, and replace the entire placeholder:

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

   
   Use this base URL for Issuer URL. The Object ID, authorization endpoint, and full OpenID Connect metadata-document URL are different values.
5. Create the client secret. Open Certificates & secrets → Client secrets → New client secret. Add a description and an expiry that fits your organization's policy, then select Add. Copy the secret's Value immediately and store it securely for Step 2. The Secret ID is not the credential, and Entra will not show the Value again after you leave this page. Record its expiry so you can replace it before sign-in is interrupted. Microsoft's credential guide.
6. Check the user's email and consent. DevStride requests the openid, email, and profile scopes. Entra only returns an email claim when the user has an email address associated with their account, so confirm your test user's email is populated and matches their DevStride membership. A sign-in username that looks like an email address is not sufficient on its own. Microsoft's email-scope guidance.
   If you need to request the email claim explicitly, use Token configuration → Add optional claim → ID → email → Add. If prompted, enable the Microsoft Graph email permission. This does not fill in a missing user email address. Microsoft's optional-claims guide.
   If your tenant restricts user consent, or you require assignment to this app, have an authorized Entra admin review API permissions and select Grant admin consent for your tenant for the required sign-in permissions. Microsoft's consent guide.

Ready to continue: you have the Issuer URL, Client ID, and secret Value. Skip the SAML path and check user access.

Entra SAML

1. Copy DevStride's two SAML values. In DevStride, open Configure Settings → Integrations → Identity Providers and copy ACS URL and SP Entity ID from Give these to your provider.
2. Create the enterprise application. In Entra, open Entra ID → Enterprise apps → New application → Create your own application. Name it DevStride, select Integrate any other application you don't find in the gallery (Non-gallery), and select Create.
3. Configure SAML. Open the new application's Single sign-on page and select SAML. In Basic SAML Configuration, select Edit and enter:

   Entra field	Paste from DevStride
   Identifier (Entity ID) — select Add identifier if needed	SP Entity ID
   Reply URL (Assertion Consumer Service URL) — select Add reply URL if needed	ACS URL

   
   Select Save before closing the panel. The OIDC Redirect URI is a different address; use the ACS URL for SAML. Microsoft's SAML setup guide.
4. Check the email claim. In Attributes & Claims, confirm that the emailaddress claim uses user.mail and that your test user's mail value matches their DevStride email. DevStride's default SAML mapping expects the full claim name http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.
   If user.mail is empty, have the directory admin populate it. Use user.userprincipalname as the claim's source only if it is the actual email address used in DevStride. Changing Name ID alone does not supply the email attribute. If you use a custom claim name, enter that exact name in DevStride's Attribute Mapping in Step 2. Microsoft's claims guide.
5. Copy the metadata. In SAML Certificates (called SAML Signing Certificate in some layouts), copy App Federation Metadata Url. This is the value for DevStride's Metadata URL field. Alternatively, download Federation Metadata XML and use its contents with Metadata XML. The certificate download, Login URL, and Microsoft Entra Identifier are not the metadata document. Microsoft's metadata guidance.

Ready to continue: you have your application's metadata URL or XML. Check user access below before returning to DevStride.

Entra user access (both protocols)

1. Open Entra ID → Enterprise apps, select your DevStride application, and open Properties. For OIDC, match the Application ID to the client ID you recorded if several apps have the same name.
2. Confirm Enabled for users to sign in? is Yes. Check Assignment required?: when it is Yes, ordinary users must be assigned before Entra will let them sign in. When it is No, Entra does not restrict sign-in to assigned users. To limit access to selected people, set it to Yes and save. Microsoft's application properties.
3. For an app that requires assignment, open Users and groups → Add user/group. Select None Selected under Users and groups, choose your test user, select Select, then Assign. Group assignment requires Entra ID P1 or P2; use individual assignments if groups are unavailable. Microsoft's assignment guide.

Use an ordinary assigned member for your final test. Entra Global Administrators can bypass the assignment requirement, so an administrator's successful login alone does not prove that members have access.

Entra setup is complete. Continue to Step 2: Add the provider in DevStride, then verify the domain and test from DevStride's sign-in page.

Okta

OIDC: open Applications → Create App Integration → OIDC → Web Application.

SAML: open Applications → Create App Integration → SAML 2.0.

Assign the application to the people who need access, then continue below.

Step 2: Add the provider in DevStride

Return to Configure Settings → Integrations → Identity Providers, select Add Identity Provider, and complete the dialog:

Select Create. Wait for Status to show active. If it shows failed, correct the settings with Edit, then select Resync.

An active provider is configured, but it will not route sign-ins until a domain is verified in Step 3.

Step 3: Verify your email domain

1. Beside the provider's unverified domain, select Verify.
2. Copy the DNS TXT record's Name and Value from DevStride. For acme.com, the full name is _devstride-challenge.acme.com. Use your own displayed value; it is unique to this claim.
3. In your DNS provider, add a TXT record with those details and save it.
4. Return to DevStride and select Check DNS. Once the domain shows verified, SSO routing for it is enabled.

DNS changes may take a few minutes or longer to become visible. Retry Check DNS after propagation. If verification keeps failing, check the record's full name and value. You can inspect the published record with:

# macOS / Linux — replace acme.com with your domain
dig +short TXT _devstride-challenge.acme.com

On Windows, use nslookup -type=TXT _devstride-challenge.acme.com.

A verified acme.com claim does not cover subdomains such as mail.acme.com; verify each email domain you use. Only one provider can hold a verified claim on a domain. DevStride does not recheck the TXT record after verification, so you may remove it then. Deleting and re-creating a provider requires a new record and a new verification.

Step 4: Confirm SSO works

Keep your current admin session open and use a private / incognito window for the test.

1. Open your DevStride sign-in page.
2. Enter the test member's work email in Username or Email.
3. Select Sign in with SSO. For a corporate Entra connection, use this button rather than the separate Sign in with Microsoft button.
4. Sign in at your identity provider and confirm you return to the expected DevStride organization with the member's existing work and permissions.

For this first test, use an active existing member with an accepted invitation and access to the Entra application. Automatic member creation is still off. If Entra already has a session, it may not ask for credentials again.

If sign-in fails, use Troubleshooting. Confirm this test succeeds before enabling the rollout options below.

Step 5 (optional): Turn on automatic member provisioning

Automatic member provisioning, also called just-in-time (JIT) provisioning, creates a DevStride account when an eligible person signs in through SSO for the first time. Leave it off if you want to invite members yourself.

After verifying at least one domain:

1. Select Edit on the provider in DevStride.
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 the organization's default invite role. If no default exists, you must choose a role here. Owner cannot be a provisioning role.

Provisioning only creates members whose email domain is verified for this provider. Entra assignment controls still apply. This setting does not enable SCIM or automatic removal of departing employees.

How your team signs in

Tell members to enter their work email on the DevStride sign-in page and select Sign in with SSO. DevStride finds the provider for their email domain and sends them to their company's sign-in page.

Existing members keep their DevStride account, work, and permissions when their corporate identity is linked. An unaccepted invitation must be accepted using their existing sign-in method first.

SSO is an additional sign-in method by default. Members with a DevStride password can still use it until you require single sign-on.

Signing out of DevStride does not sign the member out of their identity provider. To end both sessions, they must sign out of both systems.

Requiring single sign-on

After testing SSO for an ordinary member, open Login policy → Require single sign-on on the Identity Providers page. Turn it on and confirm to block password and social sign-in for your organization.

• You need an active provider with a verified domain before this setting is available.
• Existing sessions are checked against the policy at their next token refresh; enabling it does not immediately sign everyone out.
• You cannot delete your last working provider while SSO is required.

SSO and multi-factor authentication

Enterprise SSO does not pass through DevStride's own MFA challenge. If Require multi-factor authentication is on in DevStride, federated sign-in is blocked, even if the member completed MFA in Entra.

For SSO with MFA, enforce MFA at your identity provider and turn off DevStride's own MFA requirement. Coordinate that change with your identity administrator so the provider's MFA policy is in place first.

The member-facing error is Your organization doesn't allow signing in with your identity provider. If the connection appears correct, check this setting.

Keeping a provider working

Resync registers the provider's current configuration with the sign-in platform again. Use it after correcting a failed configuration.

For Entra OIDC, replace the client secret before it expires: create a new secret in Entra, copy its Value into Client Secret when editing the provider in DevStride, save, and test sign-in before removing the old secret. Leaving the field blank during an edit keeps the current secret.

For SAML, track the signing certificate's expiry in Entra and coordinate certificate renewal with your identity administrator. If you supplied metadata XML, update it when the provider's certificate or metadata changes.

Removing an identity provider

On the Identity Providers page, select Delete beside the provider and confirm. There is no separate disable switch.

• The provider stops accepting new SSO sign-ins and releases its claimed domains.
• Member accounts, work, roles, and memberships remain intact.
• If other sign-in methods are allowed, members can use them. SSO-created members may need I forgot my password to set a password.

If SSO is required, add another working provider or turn off Require single sign-on before deleting the last working provider.

Re-creating a provider requires fresh DNS verification, and automatic provisioning starts off again. The Entra application can be reused for the same protocol and DevStride environment: its redirect URI, or SAML ACS URL and SP Entity ID, remain the same. Test sign-in again after rebuilding the connection.

What Enterprise SSO does not do

• Remove departing members automatically. There is no SCIM or directory sync. Removing someone's access in Entra prevents future Entra sign-ins, but does not delete their DevStride membership or necessarily end an existing session. Remove departing members from DevStride under Configure Settings → Organization → Users as well.
• Require SSO automatically. Password sign-in remains available unless you enable Require single sign-on.
• Replace the separate social sign-in buttons. Corporate Entra connections use Sign in with SSO. The Sign in with Microsoft button is for personal Microsoft accounts. See Users, Roles & MFA.

Troubleshooting

Start with where the failure appears: Entra errors concern the application, credentials, access, or tenant policies; a DevStride error can also indicate domain routing, membership, or login policy.

See Microsoft's error-code reference for other Entra errors. When contacting support, include the error code and the failed attempt's time, but never a client secret.