Ask any IT department whether they want to manage another set of passwords for another business application and the answer is a tired, emphatic no. Each standalone credential is one more account to provision, one more account to de-provision, one more helpdesk ticket when it's forgotten, and one more unknown when an employee leaves. Enterprises solve this by centralizing identity: one corporate account, one set of credentials, one place to turn access on or off, one policy that applies everywhere. A business platform that can't participate in that centralized identity story is a platform that IT pushes back on. So the platform speaks the identity-federation protocols IT already uses, integrates with the central directory, and behaves the way a well-mannered enterprise application is expected to behave.
Identity provider integration is the core capability. The tenant is connected to the organization's central directory; users who reach the platform are sent through the identity provider to authenticate; the identity provider vouches for them and returns a signed assertion; the platform creates or looks up the matching account and starts a session. The user experience is what enterprise users expect: click sign in, get redirected to the familiar corporate login page, authenticate there (often with whatever multi-factor mechanism the organization has already standardized on), and return to the platform signed in.
Group-based role mapping is where the integration becomes genuinely useful for administrators. The identity provider already knows which groups a user belongs to — Sales, Engineering, Finance, Regional Managers, Read-Only Auditors. Those group memberships can be mapped to platform roles automatically: membership in the Sales group grants the Sales User role, membership in Finance grants the Finance role, and so on. The mapping is defined once in the tenant configuration; role assignment for new and existing users follows the directory, which means permission management is centralized where it already is rather than duplicated across every application.
Just-in-time provisioning closes the last gap in the onboarding story. When a user who's never signed in before reaches the platform, the identity provider still vouches for them, and the platform creates the account on the spot — populating the basics from the assertion, assigning roles from the group mapping, and letting the user in. No manual provisioning step, no admin having to pre-create accounts for every new hire, no onboarding delay waiting for someone to set up access. The user shows up, authenticates, and the platform accepts them because their employer already has. That's how onboarding at scale is supposed to feel.
Mixed mode allows tenants to run SSO alongside local password accounts on the same tenant. Most enterprise users sign in through the identity provider; a handful of service accounts, integration users, or break-glass admin accounts retain local credentials. This matters in practice because the real world isn't all-or-nothing: an implementation partner working on the tenant might need a local account that isn't tied to the customer's directory; a specific integration might authenticate with a dedicated local account. Mixed mode keeps those use cases viable without forcing them into the SSO flow where they don't naturally belong.
Session lifetime and re-authentication honor the identity provider's policies. An organization that requires re-authentication every eight hours can enforce that by configuring the provider accordingly; the platform respects the session lifetime the provider returns. If the provider signals that a user's session has ended, the platform's session ends too. That alignment keeps the platform from being the weak link in a strict session policy.
Logout propagation is the companion mechanism on sign-out. When a user signs out of one federated application, the provider can notify the others, and the platform terminates the corresponding session. For workflows where multiple applications share an identity, logging out of one is logging out of all — which matches what "sign out" is supposed to mean in a federated environment.
Multi-tenant routing lets different tenants connect to different identity providers. A service operating dozens of customer tenants can have each customer connect to its own directory, without provider choices leaking across tenants. Each tenant sees a sign-in flow aligned with its own organization; administrators manage their own mapping; the platform routes each incoming authentication request to the right provider based on tenant identification. For platform operators serving multiple customers, this multi-tenant isolation is what makes federation practical at all.
Fallback to local login is the safety mechanism that matters most when it's most needed. A misconfigured SSO integration — a typo in the provider URL, a certificate that's expired, a provider that's down for maintenance — shouldn't lock every user out permanently. The platform retains a local-login path for designated admin accounts so that, in the worst case, an administrator can sign in with local credentials and fix the misconfiguration. Without this fallback, a bad SSO change would be unrecoverable from inside the platform; with it, the failure mode is "inconvenient" rather than "catastrophic."
Audit of SSO events integrates with the event log. Every federation exchange — every sign-in attempt, every successful authentication, every group-to-role evaluation, every provisioning event — is recorded with enough context to investigate later. For organizations where access logs are a compliance requirement, this audit coverage is what makes the integration genuinely adoptable. The identity provider has its own logs; the platform has its own logs; together they tell the full story of who had access to what and when.
For enterprise buyers evaluating the platform, SSO support is often a threshold feature: before even considering the rest of the capabilities, the question is whether the platform fits the organization's identity strategy. With full SSO integration plus local-account mixed mode plus audit and fallback handling, the answer is yes. For the surrounding identity topics, the authentication article covers the password-based path for non-federated users, the roles and permissions article covers what those incoming group memberships actually grant, and the user invitations article covers the onboarding flow for users who don't come in through the directory.