Set up Enterprise SSO with Microsoft Entra ID
This guide connects Microsoft Entra ID — formerly Azure Active Directory — to Devs.ai using SAML 2.0. When you are done, anyone with an email address at your domain signs in with their Microsoft work account instead of a Devs.ai password.
📝 Note: Enterprise SSO is an enterprise feature and is not enabled by default. To turn it on for your organization, reach out to your Devs.ai representative.
You will need: edit access to Organization Settings in Devs.ai, an Entra ID role that can create and configure enterprise applications (Application Administrator or higher), and the list of email domains to route through Entra ID. See the overview for the full prerequisites.
Unlike the other providers, Entra ID setup starts in Entra, because Devs.ai needs your Entra identifier or metadata URL when the connection is created.
Step 1 — Create the enterprise application in Entra ID
- In the Microsoft Entra admin center, go to Identity → Applications → Enterprise applications.
- Select New application, then Create your own application.
- Enter a name, for example
Devs.ai. - Choose Integrate any other application you don't find in the gallery (Non-gallery), then select Create.
Step 2 — Start SAML setup and copy the metadata URL
- In your new application, under Manage, select Single sign-on.
- Choose SAML as the single sign-on method.
- Scroll to the SAML Certificates section and copy the App Federation Metadata Url.
You do not need to fill in the Basic SAML Configuration yet — you will do that in Step 4, once Devs.ai has generated the values it needs.
Step 3 — Create the connection in Devs.ai
- Go to Organization Settings and select Enterprise SSO (https://devs.ai/org-enterprise-sso).
- Select Add Connection.
- Enter a Connection Name, for example
Entra ID SSO. - Set Identity Provider to Microsoft Entra ID. This cannot be changed later.
- Under Domains, add each email domain you want routed through Entra ID, for example
acme.com. Press Enter or type a comma after each one. - Paste the App Federation Metadata Url from Step 2 into the field of the same name. It must start with
https://. - Select Create Connection.
Microsoft Entra ID requires either the metadata URL or a Microsoft Entra Identifier, so this field cannot be left empty for this provider.
Step 4 — Send the service provider values back to Entra ID
- On the Devs.ai connection page, find the Service Provider Configuration section and copy the ACS URL and the SP Entity ID.
- In Entra ID, on the Set up single sign-on with SAML page, select Edit on Basic SAML Configuration and enter:
| Entra ID field | Value |
|---|---|
| Identifier (Entity ID) | The SP Entity ID from Devs.ai |
| Reply URL (Assertion Consumer Service URL) | The ACS URL from Devs.ai |
- Select Save.
Leave Sign on URL, Relay State, and Logout Url empty unless you have a specific reason to set them. A Sign on URL is only needed if you plan to start sign-in from the Entra app tile, which requires Allow IdP-Initiated flow — see the overview for why that is not recommended.
Step 5 — Check the claims
Open the Attributes & Claims section in Entra ID. Entra sends the claims Devs.ai expects for this provider by default, so there is usually nothing to change:
| Devs.ai field | Claim sent by Entra ID |
|---|---|
| User ID | http://schemas.microsoft.com/identity/claims/objectidentifier |
| Email address | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress |
| First name | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname |
| Last name | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname |
If your tenant has customized the claim set, either restore these claims in Entra or update the matching fields under Attribute mapping on the Devs.ai connection page.
One thing worth checking: the emailaddress claim is sourced from user.mail in many tenants. If some of your users have no mailbox and therefore no user.mail value, point that claim at user.userprincipalname instead so every user has an email address in the assertion.
Step 6 — Assign users in Entra ID
Open Users and groups in your Entra application and assign the users or groups who should have access. Anyone not assigned cannot sign in, even if their email domain matches your connection.
Step 7 — Test and enable
- On the Devs.ai connection page, confirm the header shows the Active badge. If it shows Inactive, select Enable.
- Have one administrator — assigned to the application in Entra — sign out and sign back in with their work email address. They should be redirected to the Microsoft sign-in page.
- After signing in, check that their name and email are correct in Devs.ai. If something is missing, revisit the claims in Step 5.
- Once the test passes, announce the change and roll out to the rest of your organization.
Entra-specific troubleshooting
AADSTS700016 or "application not found in the directory" The SP Entity ID in Devs.ai and the Identifier (Entity ID) in Entra do not match. Copy the value again with the copy button rather than retyping it.
AADSTS50011 — reply URL mismatch The Reply URL in Entra must match the ACS URL on the connection page exactly, including scheme and any trailing path.
Members are redirected to Microsoft but then told they cannot access the app They are not assigned to the application. Add them, or their group, under Users and groups.
Members appear without a first or last name
Your tenant is not sending the givenname or surname claims. Add them back under Attributes & Claims, or change the Attribute mapping fields in Devs.ai to the claim names your tenant does send.
Sign-in broke roughly a year after setup Entra signing certificates expire, by default after three years, and can be rotated sooner. Because you configured the connection with the App Federation Metadata Url, the new certificate is picked up automatically — but only while that URL stays valid. If you switched to manual configuration, upload the new Certificate (Base64) from the SAML Certificates section.
Related topics
- Enterprise SSO overview — how connections work, managing them, and limitations.
- Two-step verification — how 2FA interacts with SSO.
- User permissions — who can change organization settings.