What is enterprise SSO?
Enterprise Single Sign-On (SSO) lets employees log in to your app using their company's existing identity provider — Microsoft Azure AD, Okta, Google Workspace, or similar — rather than a separate username and password. The user clicks "Sign in with your company account," is redirected to their organisation's login page, authenticates there, and is returned to your app with a verified identity.
This is built on two protocols: SAML 2.0 (an older XML-based standard still dominant in enterprise) and OAuth 2.0 / OIDC (a more modern token-based approach). Many identity providers support both. The choice is often dictated by what the customer's IT department already uses.
For B2B SaaS products targeting mid-market or enterprise customers, SSO is frequently a hard requirement during procurement — deals are lost without it.
When does your app need it?
- You're selling to organisations rather than individuals, and IT departments need central control over user access
- Enterprise customers require that when an employee leaves, their access is revoked instantly from the identity provider — not managed app by app
- Your customers use Microsoft 365 or Azure AD (very common in Australian enterprises) and expect seamless login
- You're going through a security review or procurement process where SSO is listed as a mandatory requirement
- Your customers have compliance obligations (ISO 27001, SOC 2) that require centralised identity management
- You want to eliminate password-related support tickets for enterprise accounts
How much does it cost?
Adding enterprise SSO typically adds 8–16 hours of development — roughly $1,000–$4,000 AUD.
At the lower end: integrating with a single provider (e.g., Azure AD via OIDC) using a library like Passport.js or WorkOS. The protocol is standard but setup, testing, and edge-case handling take time.
At the higher end: supporting multiple identity providers with SAML 2.0 and OIDC, handling SP-initiated and IdP-initiated flows, custom attribute mapping per customer, and per-tenant SSO configuration (where each enterprise customer brings their own IdP configuration). The attribute mapping and per-tenant config management is where complexity accumulates quickly.
How it's typically built
SAML 2.0 flows involve XML metadata exchange between your app (the Service Provider) and the customer's identity provider. Libraries like node-saml or samlify handle the XML signing and verification. Your app stores each customer's IdP metadata and routes login requests to the correct provider based on the user's email domain.
OIDC flows are cleaner — similar to social login but pointed at an enterprise IdP. Azure AD, Okta, and Google Workspace all support OIDC well. The flow is an OAuth 2.0 authorisation code flow with ID token verification.
WorkOS or Auth0 with the Enterprise Connections add-on are managed services that abstract the SAML complexity significantly, reducing integration time but adding per-user cost. For high-volume apps this adds up; for apps with a small number of large enterprise customers it often makes sense.
Attribute mapping is important: the identity provider sends claims (user attributes) that your app must translate to internal fields — employee ID, department, role, and so on.
Questions to ask your developer
- Which protocols will you support — SAML 2.0, OIDC, or both? Most Australian enterprise customers on Microsoft 365 / Azure AD can use either, but some legacy systems require SAML.
- How is per-tenant IdP configuration managed? Each enterprise customer needs their own metadata stored. How is this added, updated, and tested without developer involvement?
- Do you handle both SP-initiated and IdP-initiated flows? SP-initiated (user starts at your app) is straightforward. IdP-initiated (user starts from their company portal) has security implications and requires extra handling.
- How are attribute mappings handled? Different identity providers send user attributes with different names. Ask how your app maps these to internal fields.
- What happens if the customer's IdP is unavailable? Is there a fallback login method for admins?
See also: Email & password login · Multi-tenant organisations · Two-factor authentication · App cost calculator