Skip to main content

Enterprise SSO

Single sign-on (SSO) allows users to sign in to multiple applications with a single set of credentials. It’s a general term that refers to a user’s ability to log in once and access multiple applications or resources without needing to log in again.

Enterprise SSO is a specialized type of SSO designed for organizations, simplifying authentication for employees across workplace tools. For example: An Acme Company employee uses their Google Workspace account ([email protected]) to sign into Slack, Zoom, Trello, Office Suite, and GitHub without re-entering credentials. IT admins centrally manage access permissions and revoke access instantly if an employee leaves.

Logto provides:

  • Pre-built connectors: Easy integration with popular identity providers (e.g., Google Workspace, Microsoft Entra ID, Okta).
  • Custom connectors: Integrate any SAML/OIDC-compliant identity provider for unique organizational needs.
  • Domain-based routing: Automatically route users via email domain (e.g., @client-a.com) to their company’s IdP.
  • SP-initiated & IdP-initiated SSO: Users can start logins from your app or their IdP dashboard for access.
  • Just-in-time (JIT) provisioning: Automatically add enterprise users to their organizations upon first enterprise SSO login—no manual invitations required. Learn about JIT provisioning.

Do I need enterprise SSO?​

Key benefits of enterprise SSO:

  • Centralized security: Organizations enforce strict access policies (e.g., multi-factor authentication, role-based permissions) across all integrated apps.
  • Streamlined access: Employees avoid password fatigue and gain seamless access to tools.
  • Compliance: Simplifies audit trails and meets regulatory requirements (e.g., GDPR, HIPAA).
  • Flexibility: Supports integration with legacy systems or niche IdPs via SAML/OIDC.

Enterprise SSO is a must if you:

  • Offer B2B/B2C2B services (e.g., SaaS) that need to integrate with client’s corporate IdPs.
  • Operate in regulated industries (e.g., healthcare, finance) where centralized identity and access management is mandatory.
  • Aim to win enterprise contracts where security and seamless onboarding are deal-breakers.

You don’t need Enterprise SSO right away if your product is newly launched. Consider enabling it when:

  • A high-value client requires it for security compliance or as part of their procurement process. Without it, they may not proceed with the purchase.
  • Your product targets enterprise-tier customers, where SSO is a standard expectation for security and user management.

With Logto, enabling Enterprise SSO is effortless—no-code, no breaking changes, just one click:

  1. Add a dedicated enterprise connector for the client’s IdP.
  2. Bind their email domain (e.g., @client-a.com).
  3. Existing users with that domain automatically switch to Enterprise SSO, with account linking between their email address and SSO identifier—no disruption to access.

Key components of enterprise SSO​

  • Identity provider (IdP): A service that verifies user identities and manages their login credentials. After confirming a user's identity, the IdP generates authentication tokens or assertions and allows the user to access various applications or services without needing to log in again. Essentially, it's the go-to system for managing employee identities and permissions in your enterprise. Examples: Okta, Azure AD, Google Workspace, LastPass, OneLogin, Ping Identity, Cyberark, etc. Learn more about IdP.
  • Service provider (SP): A system or application that requires user authentication and relies on the Identity Provider (IdP) for authentication. The SP receives authentication tokens or assertions from the IdP, granting access to its resources without requiring separate login credentials. Examples: Slack, Shopify, Dropbox, Figma, Notion, etc…and your service. Learn more about SP.
  • Enterprise identity: Typically identified by their use of a company email domain for login. This enterprise email account finally belongs to the company.

Supported SSO workflow​

  • IdP-Initiated SSO: In IdP-initiated SSO, the Identity Provider (IdP) primarily controls the single sign-on process. This process begins when a user logs into the IdP's platform, such as a company portal or a centralized identity dashboard. Once authenticated, the IdP generates an authentication token or assertion, which is then used to seamlessly grant the user access to multiple connected services or applications (SPs) without requiring additional logins. IdP-initiated SSO
  • SP-Initiated SSO: In SP-initiated SSO, the Service Provider (SP) takes the lead in initiating and managing the single sign-on process, often preferred in B2B scenarios. This scenario occurs when a user attempts to access a specific service or application (the SP) and is redirected to their IdP for authentication. Upon successful login at the IdP, an authentication token is sent back to the SP, granting the user access. Logto supports SP-initiated SSO for your B2B services. SP-initiated SSO

Supported SSO protocols​

  • SAML: Security Assertion Markup Language (SAML) is an XML-based open standard for exchanging authentication and authorization data between an IdP and SP. his protocol is particularly adept at handling complex enterprise-level security requirements.
  • OIDC: OpenID Connect (OIDC) is a simple identity layer built on top of the OAuth 2.0 protocol. It employs JSON/REST for communication, making it more lightweight and better suited for modern application architectures, including mobile and single-page applications (SPAs).

FAQs​

How to add SSO connector buttons and directly sign in with SSO provider on my website?​

Logto allows you to add social login buttons to your website and initiate the SSO sign-in process directly without showing the default sign-in form. Check out our Direct sign-in guide for detailed instructions.

How many enterprise SSO connectors do I need?​

Each client requires a unique connector to ensure isolated configurations, employee management, and permissions control. For example:

  • Client A (Okta): ”Enterprise Connector A” using Okta for @client-a.com.
  • Client B (Okta): Another “Enterprise Connector B” using Okta for @client-b.com.
  • Client C (Azure AD): ”Enterprise connector C” using Microsoft Azure AD for @client-c.com.

If you need multi-client access without a per-client setup, consider using social connectors (e.g., Google, Facebook) instead, as they do not require client-specific IdP configurations.

Enterprise SSO experience

IdP-initiated SSO vs SP-initiated SSO

Enterprise SSO: What it is, how it works, and why it matters

 The art of single sign-on