Single sign-on: an overview
Single sign-on (SSO) lets people sign in to MobilityManager with their existing organizational identity instead of a separate password. This article gives an overview of how SSO works, which providers are supported, and how it is set up.
What SSO gives you
- Users sign in with the account they already use at work, through your identity provider.
- Passwords are managed centrally by your provider, not stored in MobilityManager.
- New users can be created automatically on their first successful SSO sign-in.
Supported providers
MobilityManager supports OpenID Connect (OIDC) providers. Each company (tenant) is configured for one provider:
| Provider setting | Use it for | Default button text |
|---|---|---|
| AzureAD | Microsoft Entra ID / Azure Active Directory | Login with Microsoft |
| Keycloak | Keycloak realms | Login with Keycloak |
| ADFS | Active Directory Federation Services | Login with ADFS |
| Generic OIDC | Any standards-compliant OIDC provider | Login with SSO |
Note: Email and password sign-in always remains available alongside SSO. Enabling SSO for a company adds a single sign-on button; it does not disable local login.
What signing in with SSO looks like
- Select your company on the sign-in page. If SSO is enabled, a single sign-on button appears (with the provider's default text or a custom label set by your administrator).
- Choose the SSO button. You are redirected to your identity provider to authenticate.
- After you authenticate, your provider returns you to MobilityManager, which validates the response and starts your session.
How the platform keeps it secure
When your provider returns a signed identity token, MobilityManager fetches the provider's published configuration and signing keys and verifies the token's signature, issuer, audience, and validity period before trusting it. Your identity is taken only from the verified token, never from unverified data. If any check fails, the sign-in is refused. A state value is also used during the redirect to guard against cross-site request forgery.
Who configures SSO
SSO is configured per company by an administrator (SystemAdmin). The administrator enables SSO and supplies the connection details for your provider:
- Provider — AzureAD, Keycloak, ADFS, or generic OIDC.
- Authority — the base URL of your provider or realm.
- Client ID and Client secret — the application registered at your provider. The secret is stored securely and never shown back in the app.
- Redirect URI — where the provider returns users after they authenticate.
- Scopes — defaults to
openid profile email. - Button text — an optional custom label for the sign-in button.
Tip: On the first SSO sign-in, new users are created automatically with the Driver role. See "How single sign-on users are provisioned" for details.
Related
- Signing in with Azure AD (Microsoft Entra ID)
- Signing in with Keycloak
- Signing in with ADFS or a generic OIDC provider
- How single sign-on users are provisioned
