Azure AD Single Sign-On
With Azure AD SSO enabled, your employees sign in to Ditio using the Microsoft account they already have — no separate Ditio password to manage, and access follows your directory’s own security policies (MFA, conditional access, offboarding). Setup is a one-time app registration in your Azure tenant plus a short configuration step on Ditio’s side.
How Ditio decides to use SSO
Section titled “How Ditio decides to use SSO”Ditio routes users to your directory by the domain of their email address.
When someone enters [email protected] on the Ditio login screen, we
match yourcompany.no against the domains registered for your company and
redirect to Microsoft.
Two consequences worth planning for:
- Users whose Ditio profile carries a personal email address (Gmail, Hotmail, iCloud…) are not routed to SSO. They keep signing in with their phone number as usual. This is common for site crews.
- A user’s Ditio profile email must match the User Principal Name (UPN) of their Microsoft account. If it doesn’t, sign-in fails with “Email not found in Ditio”.
SCIM provisioning keeps the two in sync automatically, so most customers set up both together.
Prerequisites
Section titled “Prerequisites”- Access to your organization’s Azure Portal with permission to create app registrations
- Your six-digit Ditio company ID (e.g.
012345) — contact [email protected] if you’re unsure
Setup steps
Section titled “Setup steps”1. Register an application in Azure
Section titled “1. Register an application in Azure”- Sign in to the Azure Portal and make sure you are in the correct directory
- Go to Microsoft Entra ID (Azure Active Directory) → App registrations
- Click New registration
- Fill in:
- Name: choose a name (e.g. “Ditio SSO”)
- Redirect URI: leave blank for now — you’ll add the full list in step 2
2. Configure redirect URIs
Section titled “2. Configure redirect URIs”Go to Authentication → Add a platform → Web, and add the URIs
below. Replace {ditio_companyId} with your six-digit Ditio company ID.
Ditio runs three sign-in hosts. Which one a user reaches depends on the client they use — the web app and the mobile apps do not share a host — so register all of them, or SSO will work in one place and fail in another.
Required — sign-in. Without these, Microsoft rejects the login with
AADSTS50011.
https://identity.ditio.app/signin-aad-{ditio_companyId}https://identity.ditio.no/signin-aad-{ditio_companyId}https://identity.ditio.dev/signin-aad-{ditio_companyId}For example, a company with Ditio company ID 012345 would add
https://identity.ditio.app/signin-aad-012345.
Optional — single sign-out. Add these only if you want signing out of Microsoft to also sign the user out of Ditio. Sign-in works without them.
https://identity.ditio.app/signout-aad-{ditio_companyId}https://identity.ditio.app/signout-callback-aad-{ditio_companyId}https://identity.ditio.no/signout-aad-{ditio_companyId}https://identity.ditio.no/signout-callback-aad-{ditio_companyId}https://identity.ditio.dev/signout-aad-{ditio_companyId}https://identity.ditio.dev/signout-callback-aad-{ditio_companyId}3. Enable ID tokens
Section titled “3. Enable ID tokens”Still under Authentication, tick ID tokens under Implicit grant and hybrid flows, and save.
4. Send the identifiers to Ditio
Section titled “4. Send the identifiers to Ditio”From the Overview tab, copy the following and send to [email protected]:
- Application (client) ID
- Directory (tenant) ID
Neither value is a credential, but please tell us which email domains the
registration should cover (e.g. yourcompany.no) so we route the right users.
5. Ditio activates SSO
Section titled “5. Ditio activates SSO”We add your directory to Ditio’s identity service and confirm when it is ready to test. Activation requires a release of that service, so allow a couple of working days.
SSO runs alongside your existing sign-in methods rather than replacing them. Users who enter an address on your registered domains go to Microsoft; signing in with a phone number and password keeps working. This is how most Ditio customers on SSO run, and it means a problem on the Microsoft side never leaves anyone without a way into Ditio.
Restricting sign-in further — so users on your domains can only come through Microsoft — is possible, and some customers do it. Talk to us before deciding: it removes the fallback route for those accounts, and it is a change to Ditio’s identity service rather than a setting that can be switched on request.
Common issues
Section titled “Common issues”| Issue | Cause | Fix |
|---|---|---|
AADSTS50011 / redirect error after Microsoft login | A redirect URI is missing or has a typo | Compare the Authentication tab against the list above — every URI must match exactly, including your company ID |
| Works in the browser but not in the Ditio app | Only the identity.ditio.app URIs were added | Add the identity.ditio.no URIs — the mobile apps sign in against that host |
| Sign-in works in production but not test | Test URIs not added | Add the identity.ditio.dev URIs |
| ”ID token missing” style errors | ID tokens not enabled | Tick ID tokens under Implicit grant and hybrid flows |
| ”Email not found in Ditio” | The user’s Microsoft UPN doesn’t match the email on their Ditio profile, or they have no profile in the company | Correct the email on the Ditio profile, or provision the user via SCIM |
| Some users still get the password screen | Their Ditio profile uses a personal email domain | Expected — only users on your registered domains are routed to SSO |
Related
Section titled “Related”- SCIM User Provisioning — automatically create and deactivate the accounts users sign in to
- Authentication — API authentication (machine-to-machine, separate from user SSO)
- Questions? Contact [email protected] with your Application (client) ID and Directory (tenant) ID