Skip to content

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.

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.

  • 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
  1. Sign in to the Azure Portal and make sure you are in the correct directory
  2. Go to Microsoft Entra ID (Azure Active Directory) → App registrations
  3. Click New registration
  4. 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

Go to AuthenticationAdd a platformWeb, 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}

Still under Authentication, tick ID tokens under Implicit grant and hybrid flows, and save.

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.

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.

IssueCauseFix
AADSTS50011 / redirect error after Microsoft loginA redirect URI is missing or has a typoCompare 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 appOnly the identity.ditio.app URIs were addedAdd the identity.ditio.no URIs — the mobile apps sign in against that host
Sign-in works in production but not testTest URIs not addedAdd the identity.ditio.dev URIs
”ID token missing” style errorsID tokens not enabledTick 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 companyCorrect the email on the Ditio profile, or provision the user via SCIM
Some users still get the password screenTheir Ditio profile uses a personal email domainExpected — only users on your registered domains are routed to SSO
  • 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