Signing in with Azure AD (Microsoft Entra ID)
This article explains how single sign-on with Azure Active Directory (Microsoft Entra ID) works in MobilityManager, both for people signing in and for the administrator who configures it.
Signing in with Microsoft
- Open the sign-in page and select your company (tenant).
- Choose the single sign-on button. When the provider is Azure AD, its default label is Login with Microsoft (your administrator may have set a custom label).
- You are redirected to Microsoft to sign in with your organizational account and complete any multi-factor prompts.
- Microsoft returns you to MobilityManager, which verifies the response and starts your session.
Note: If this is your first time signing in with Azure AD, an account is created for you automatically with the Driver role. See "How single sign-on users are provisioned."
What your administrator configures
SSO is set up per company by a SystemAdmin. For Azure AD, register an application in your Microsoft Entra tenant and enter these values in MobilityManager:
| Setting | Value for Azure AD |
|---|---|
| Provider | AzureAD |
| Authority | Your Entra authority URL, for example https://login.microsoftonline.com/<directory-id>/v2.0 |
| Client ID | The application (client) ID from the app registration |
| Client secret | A client secret created for the app registration (stored securely, never displayed back) |
| Redirect URI | The MobilityManager callback URL, also registered as a redirect URI in Azure |
| Scopes | Defaults to openid profile email |
| Button text | Optional; defaults to "Login with Microsoft" |
How the Azure AD flow works
When a user starts SSO, MobilityManager builds an authorization request to the Azure endpoint at {authority}/oauth2/v2.0/authorize, requesting an authorization code. For Azure AD, the request also includes a nonce and a state value for added protection. After the user authenticates, Microsoft returns an identity token that MobilityManager validates against Azure's published signing keys, issuer, and audience before creating the session.
Tip: Make sure the redirect URI registered in Azure exactly matches the redirect URI configured in MobilityManager, including scheme and path. A mismatch is the most common cause of a failed Azure AD sign-in.
Troubleshooting
| Symptom | Likely cause |
|---|---|
| Redirect fails at Microsoft | Redirect URI not registered or misspelled in the app registration. |
| "Identity provider token validation failed" | Wrong authority, wrong client ID as audience, or a clock skew beyond the allowed tolerance. |
| "OIDC configuration is incomplete for this tenant" | Authority or client ID is missing in the company's SSO settings. |
| An email account already exists | A local password account uses the same email; an administrator must link it explicitly. |
Related
- Single sign-on: an overview
- Signing in with Keycloak
- Signing in with ADFS or a generic OIDC provider
- How single sign-on users are provisioned
