The short version
For most schools, nothing needs to be set up. The "Sign in with Microsoft" button on the Steplab login page works out of the box with any Microsoft work, school or personal account.
The single most important thing to understand is this:
Steplab matches your Microsoft account to your Steplab account by email address. As long as the email address on a person's Microsoft account is the same as the email address on their Steplab account, signing in with Microsoft will "just work".
There is no separate setup, tenant connection, or app installation required on your side for this to function.
How it works
A user clicks Sign in with Microsoft on the Steplab login page.
They're sent to Microsoft's standard sign-in screen, where they log in with their normal Microsoft credentials (and complete MFA if your organisation requires it).
Microsoft confirms who they are and returns their email address to Steplab.
Steplab looks for an existing Steplab account with that exact email address and, if it finds one, signs the person in.
Behind the scenes, Steplab uses Microsoft's standard, multi-tenant sign-in service (the same OpenID Connect / OAuth 2.0 flow used by many other applications) and reads only basic profile information – essentially the user's email address. Steplab does not read mailboxes, files, calendars or any other data from your Microsoft environment.
"How do we connect Steplab to our Microsoft 365 tenant?"
This is the most common question we get, and the good news is reassuring: there is no tenant-to-tenant connection to set up.
Steplab's Microsoft sign-in is a multi-tenant integration. It accepts sign-ins from any Microsoft organisation automatically, so there is no need to:
register Steplab as an application in your Azure / Entra portal,
share a tenant ID, client secret, or any credentials with us,
create a connector or enterprise application, or
have your IT team configure anything in Microsoft 365.
If your IT manager is keen for Steplab to "align with other software you use" by offering Microsoft sign-in, the answer is simply: it already does. Your staff can start using the Microsoft button immediately.
One caveat: tenants that restrict third-party apps
Some organisations lock down their Microsoft tenant so that staff cannot sign in to third-party applications without an administrator first approving them (this is Microsoft's "admin consent" / user-consent policy, and is a setting on your side, not in Steplab).
If your tenant is configured this way, the first person to try signing in may see a message from Microsoft saying that an administrator needs to approve the app. In that case, a Global Administrator or Application Administrator in your Microsoft environment can grant approval through the usual Microsoft admin process for enterprise/third-party applications. This is the only scenario in which your IT team would need to take any action, and it is governed entirely by your own Microsoft policies.
"Our users were registered with email aliases, not their Microsoft usernames"
This is the other situation schools frequently raise, and it's worth understanding clearly.
Because Steplab matches accounts by email address, sign-in only works when the email Microsoft reports for a user is the same as the email held on their Steplab account. If your staff were added to Steplab using addresses that differ from their Microsoft identities (for example, an alias such as [email protected] in Steplab, but a Microsoft username of [email protected]), the Microsoft button will not find their account.
A subtle but important point about Microsoft accounts: a person can have two relevant email values in Microsoft:
their user principal name (UPN) – effectively their Microsoft username, used to sign in, and
their primary email address (the "mail" attribute) – which is sometimes different.
By default, Steplab uses the UPN (sign-in username) to match accounts. For most schools the UPN and the email address are the same, so this is invisible. But if your school's "real" staff email addresses live in the mail attribute and differ from the UPN, matching can fail.
How to resolve email mismatches
You have a few options, depending on the situation:
Make the email addresses match (recommended where practical). Ensure each person's Steplab email address matches the email/username that Microsoft will report for them. This can be done either by updating the email addresses held in Steplab, or by aligning the addresses in your Microsoft environment. For a small number of users this is usually the quickest fix.
Ask us to prefer your "mail" address instead of the username. If your staff's genuine email addresses are held in Microsoft's mail attribute rather than the sign-in username, we can configure Steplab to prefer the mail value for your school's email domain(s). Just contact us (see below) and tell us the domain(s) involved – for example
yourschool.org– and we'll arrange it.Let people keep using their existing sign-in method. Microsoft sign-in is optional. Anyone whose email doesn't currently match can continue signing in with their email address and password as normal while you sort out the addresses.
If you have a mix of users – some whose addresses already match and some who were added under aliases – option 1 (tidying up the mismatched ones) combined with option 2 (if there's a consistent pattern across the school) is usually the cleanest approach. We're happy to help you work out the best route.
Things to be aware of
Users must already exist in Steplab. Signing in with Microsoft does not create a new Steplab account on its own. People are added to Steplab in the usual way (typically invited by a school lead). New users activating an invitation can choose to set their account up using Microsoft, but the Microsoft button on the main login page only works for people who already have a Steplab account or a pending invitation.
There is no "Microsoft only" enforcement setting. Steplab doesn't provide a school-level switch to force everyone to sign in with Microsoft. Sign-in methods (password, Microsoft, Google, passkey) generally sit side by side. In practice, once someone has signed in with Microsoft and has never set a Steplab password, the system will steer them back to Microsoft rather than offering a password – but this happens per user, automatically, rather than being a policy you configure.
Email matching a common issue. Almost every Microsoft sign-in problem comes down to the email address Microsoft reports not matching the email address on the Steplab account. If a member of staff can't sign in with Microsoft, the first thing to check is whether those two addresses are identical.
No data is read from your tenant. Steplab only uses Microsoft to confirm identity and retrieve the user's email address. It does not access mailboxes, documents, or other Microsoft 365 data.
Getting help
If you'd like us to:
prefer your school's "mail" addresses over Microsoft usernames for matching,
help reconcile users who were added under aliases, or
troubleshoot a member of staff who can't sign in with Microsoft,
please get in touch with our support team at [email protected] or use our live chat. It helps if you can tell us your school's email domain(s) and a couple of example accounts that aren't working, so we can pinpoint the cause quickly.