The short version
- Single sign-on lets people open desk booking with the account they already have, so there is no extra password to issue, reset or revoke
- Okta and Microsoft Entra ID both connect over SAML or OIDC, and the setup is the same shape in each: create the app, exchange metadata, map the email claim, test one user, then enforce
- SSO does not remove leavers. That is SCIM provisioning, and it is the part teams skip until an ex-employee is still holding a desk
- Agree what your directory groups mean before you switch anything on. Retrofitting roles onto a live directory is where these projects lose a fortnight
Desk booking gets bought by facilities and inherited by IT. The moment it moves, the questions change. Nobody in IT cares how the floor plan looks. They care how people sign in, who creates the accounts, and what happens the day somebody leaves.
Single sign-on answers the first of those. Here is how it works with the two identity providers most organisations already run, and what it does not solve on its own.
What single sign-on actually does
Single sign-on means your identity provider holds the credentials and vouches for the user. Someone opens the booking tool, gets redirected to Okta or Microsoft, authenticates there, and returns carrying a signed assertion that says who they are. The booking system never sees a password. It trusts the provider. That is why SSO removes work rather than adding it: your existing password policy, your MFA and your conditional access rules all apply automatically, with nothing configured twice.
SAML or OIDC
Two protocols do the same job. SAML is older, XML based, and still the default in most enterprise deployments. OIDC is newer, built on OAuth 2.0, simpler to configure and better suited to mobile. If your other applications are on SAML, use SAML and keep one pattern across the estate. If you are starting fresh, OIDC is the easier build. HybridHero supports both, so the choice is yours rather than ours.
The setup, provider by provider
The steps are the same shape in both consoles. Only the wording differs, which is worth knowing if you are following a guide written for the other one.
| Step | Microsoft Entra ID | Okta |
|---|
| Create the app | Enterprise applications, then create your own application | Applications, then create app integration |
| Choose the protocol | Single sign-on, then SAML | SAML 2.0 |
| Details to paste in | Identifier and reply URL from the booking platform | Single sign-on URL and audience URI |
| Identifier to send back | Federation metadata URL | Okta metadata URL |
| The claim that matters | Email address, since it is what the booking system matches on | Name ID format set to email address |
| Roll out | Assign one test user, sign in as them, then assign the group | Assign to a test user, then to the group, and add group push if you want directory groups to become roles |
Entra ID is what Azure Active Directory is now called, so older documentation may still say Azure AD. If your organisation already runs Microsoft 365 for calendars and Teams, the same directory drives calendar integration, so room and desk bookings end up reading one source of truth for who is who.
The part people forget: SCIM
SSO controls how somebody signs in. It does nothing about whether their account should exist at all.
Without provisioning, a leaver keeps their account in the booking system after their directory account is disabled. They cannot sign in, which feels safe enough, but their bookings still hold desks, they still appear in team views, and they still count in your reporting. Six months of that and the numbers stop meaning anything.
SCIM provisioning fixes it. The directory pushes creates, updates and deactivations to the booking platform, so joiners appear with the right team and leavers disappear the same day. If you are still evaluating tools, this is the question that separates them: SSO is common, SCIM is not.
Agree group mapping before you switch on
The failure mode in these projects is rarely technical. It is that nobody agreed what the directory groups mean. Work out first which groups map to which offices, which map to teams for bulk booking, and who needs administrator rights. Doing that on paper takes an afternoon. Retrofitting it after a thousand people already have accounts takes considerably longer.
Keep administrator rights narrow while you are at it. Role-based access control exists so a site manager can run their own building without seeing data for the whole organisation.
What to test before you enforce
Run these five before you turn SSO on for everybody. Each one maps to a support ticket you would otherwise receive in week two.
| Test | What it proves |
|---|
| A new starter signs in | They appear with the right team and the right office, with no manual setup |
| A leaver is deactivated | The account closes and their future bookings are released rather than held |
| Someone changes team | They move to the correct desks and rooms without a ticket |
| Sign-in on mobile | The redirect works in the app, not only in a desktop browser |
| Break-glass admin | You can still get in if the identity provider is unavailable |
That last one gets skipped and then remembered at the worst possible moment. Keep one local administrator account outside SSO.
Frequently asked questions
Do I need SSO for desk booking?
Not for a small office. For anything above roughly fifty people, or anywhere IT owns the access review, SSO stops being a nicety. It removes the separate password, applies your existing MFA rules automatically, and gives you one place to cut access.
What is the difference between SSO and SCIM?
SSO is authentication: proving who somebody is at the moment they sign in. SCIM is provisioning: creating, updating and deactivating the account itself. You can have SSO without SCIM, and many tools offer exactly that, which is why leavers linger.
Does SSO work with Microsoft 365 and Okta at the same time?
Most organisations run one identity provider. If you genuinely have two, for example after an acquisition, the usual pattern is to federate one into the other rather than connecting both to every application.
Is SSO included or an upgrade?
It varies by vendor and it is worth asking directly, because SSO is commonly held back for the top tier. Confirm which tier includes SAML, which includes SCIM, and whether either carries a separate charge before you compare anything.
How long does SSO setup take?
The technical configuration is usually under an hour with someone who has admin rights in both systems. Agreeing group mapping and testing joiners and leavers properly is the part that takes real time, and the part worth not rushing.
What happens if the identity provider goes down?
Nobody can sign in through SSO, which is why you keep one local administrator account outside it. Existing bookings are unaffected, and door access and other systems carry on as normal.
Where this fits
If you are still choosing a platform, the comparison of desk booking tools with SSO and SCIM covers which vendors include what, and at which tier.
HybridHero supports SAML and OIDC single sign-on, SCIM provisioning with Microsoft Entra ID and Okta, role-based access control and audit logs, and is ISO 27001 certified. If you want to see the administrator side before committing, the product tours walk through user setup, roles and permissions on the real interface.