Overview
This article walks through configuring single sign-on (SSO) for Mobaro using Microsoft Azure Active Directory (Azure AD). Once SSO is enabled, your team signs in to Mobaro using their existing Azure credentials — no separate password to manage, and access can be governed entirely through your organization's identity provider.
Why this matters: Centralizing authentication through Azure AD lets you enforce password policies, multi-factor authentication, and conditional access at the identity layer. Removing a User in Azure immediately removes their access to Mobaro.
Required: Your organization must be enabled for SSO on the Mobaro side before you can complete this setup. If SSO isn't yet active for your account, contact [email protected] to activate it.
Setup at a glance:
Step 1 — Register Mobaro as an app in Azure AD with the right redirect URI.
Step 2 — Copy the Application (client) ID and OpenID metadata URL.
Step 3 — Generate a client secret and copy its value.
Step 4 — Send the three values to Mobaro support; we configure on our side and confirm.
What you'll need
Azure AD admin access — Permission to create and manage App registrations in your Azure tenant.
Mobaro Super User — A way to share the resulting credentials with the Mobaro team.
An expiry plan — Decide how long the client secret should live and who's responsible for rotating it before it expires.
Step 1: Register Mobaro as an app in Azure AD
1. Open App registrations and create a new one
In the Azure portal, open Azure Active Directory, select App registrations, and click New registration.
2. Name the registration
Enter a recognizable name (e.g., Mobaro).
3. Configure the redirect URI
Under Redirect URI, select Web and enter the following URL exactly:
Critical: The redirect URI must match exactly, character for character. A trailing slash, a typo, or wrong casing will cause the SSO handshake to fail. Copy and paste rather than retyping.
4. Register the app
Click Register.
Step 2: Copy the Application (client) ID and metadata URL
1. Copy the Application (client) ID
From the registered app's Overview page, copy the value in the Application (client) ID field. Save it somewhere secure — you'll send it to Mobaro in Step 4.
2. Open Endpoints and copy the metadata URL
Click Endpoints at the top of the Overview page, then copy the OpenID Connect metadata document URL. Save it alongside the Application ID.
Step 3: Generate a client secret
1. Open Certificates & secrets and add a new secret
In the registered app's left navigation, click Certificates & secrets, then click New client secret.
2. Set description and expiration, then create
Enter a description (e.g., Mobaro), choose an expiration period, and click Add. Track the expiration date — you'll need to rotate the secret with Mobaro before it expires.
3. Copy the secret Value
Copy the Value shown for the new secret. Save it with your Application ID and metadata URL.
Critical: The secret Value is shown only once, immediately after creation. If you navigate away before copying it, you'll need to delete the secret and create a new one. Azure will never show the value again.
Best practice: Set a calendar reminder for 30 days before the secret's expiration date. Rotating the secret takes 5 minutes; recovering from an unexpected expiration is downtime.
Step 4: Send the credentials to Mobaro
Mobaro needs three values to complete the configuration on our side:
Value | From |
| Step 2 |
| Step 2 |
Client Secret Value | Step 3 |
Use the button below to send these to our team. The pre-filled email opens in your default mail client with the right subject line and a template for the values.
Note: Once Mobaro receives your credentials, configuration on our side typically takes one-three business days. You'll receive confirmation when SSO is live, after which your Users can sign in with their Azure AD accounts.
Frequently asked questions
Q: What happens to existing Mobaro password logins after SSO is enabled?
A: Behavior depends on how Mobaro configures your tenant. Typically, password logins for SSO-enabled domains are disabled in favor of the Azure flow. If you need a hybrid setup or staged rollout, mention that when you send your credentials.
Q: My users get an error after sign-in. What should I check first?
A: Nine times out of ten it's the redirect URI. Confirm in Azure that the URI matches Step 1 exactly — no trailing slash, correct casing, no extra characters. If that's correct, verify the client secret hasn't expired.
Q: How do I rotate the client secret before it expires?
A: Generate a new secret in Azure (Step 3), then send the new Value to [email protected]. Mobaro will swap it on our side. Once the new secret is in place, delete the old one in Azure.
Q: Can I restrict SSO to specific Azure AD groups?
A: Yes, through Azure AD's Enterprise applications assignment settings. Configure that on the Azure side; Mobaro will trust whatever Users Azure presents.
Q: Does SSO work for the Mobaro mobile app?
A: Yes. Once SSO is configured, both the web Backend and the mobile app use the same Azure flow.
Q: We use a different identity provider (Okta, Google Workspace, etc.). Can Mobaro support those?
A: Mobaro's standard SSO setup is documented for Azure AD. If you use a different OpenID Connect–compatible provider, contact [email protected] with the provider details and we'll advise on the path forward.