User directory and single sign-on

Every service your company uses has its own user database. GitHub has users. Slack has users. AWS has IAM users. Your CRM, analytics, project management — each maintains a separate list of who can log in.

This becomes a problem fast. When someone joins, you create accounts everywhere. When they leave, you need to remember every service they had access to. When someone's password is compromised, there's no central place to lock them out.

A user directory solves this by becoming the single source of truth for identity. All your users exist in one place. Services authenticate against that directory instead of maintaining their own user databases. When someone leaves, you disable one account, and they lose access everywhere.

What is a user directory?

A user directory (also called an identity provider or IdP) is a central database of user accounts. It stores:

• Who your users are (names, email addresses)
• Authentication credentials (passwords, MFA settings)
• Group memberships (engineering, marketing, admins)
• Which applications each user can access

When a user tries to log into a connected application, the application asks the directory: "Is this person allowed in?" The directory handles authentication and returns a yes/no answer plus any relevant user information.

This is the foundation of Single Sign-On (SSO). Users authenticate once with the directory, then access multiple applications without re-entering credentials.

The real benefit: control over company data

A user directory isn't just about convenience. It's about ensuring your company actually owns and controls access to its own data.

Work accounts vs personal accounts

Without a directory, employees often sign up for work tools using personal email addresses. The designer uses their personal Gmail to create a Figma account. A developer signs up for GitHub with their personal email. Marketing creates social media accounts tied to someone's personal phone number.

This creates serious problems:

The company doesn't own the accounts. That Figma account with all your design assets? It belongs to the employee's personal email. When they leave, you have to ask nicely for access. If they don't cooperate, you might lose everything.

No visibility into what exists. You can't query "what accounts does this person have?" because there's no central record. Each account lives in isolation.

Password resets go to personal email. If someone forgets a password, the reset link goes to their personal inbox. After they leave, you can't recover the account.

Personal accounts get compromised. People reuse passwords. Their personal email gets phished. Now attackers have access to your company data through a personal account you don't control.

What a directory gives you

When all employees use work accounts from your directory:

You own every account. [email protected] is your domain. You control DNS, email routing, and password resets. The employee uses the account; the company owns it.

Complete visibility. Query the directory: "Show me all active users." Check SSO logs: "What did this person access?" You have a full picture of who exists and what they can reach.

Instant lockout capability. Disable the directory account, and every connected service becomes inaccessible. No chasing down individual accounts.

Consistent security policies. Password requirements, MFA enforcement, session timeouts — set once, applied everywhere. No accounts with weak passwords because "that service doesn't enforce it."

Audit trail. Who logged in, when, from where. Required for compliance. Impossible without centralized identity.

The cost of getting this wrong

Real scenarios that happen without proper directory control:

Scenario 1: The departed designer Designer leaves. Nobody realizes the Figma account was created with their personal email. Three months later, the company needs to update the design system. The account is locked behind the ex-employee's personal email, which they're not checking. All design assets are inaccessible.

Scenario 2: The compromised personal Gmail Developer uses personal Gmail for GitHub. Their Gmail gets phished (unrelated to work). Attacker finds GitHub credentials in saved passwords. Now they have access to your private repositories, including secrets someone accidentally committed.

Scenario 3: The social media takeover Marketing manager's personal phone number is on the company's Instagram account for 2FA. They leave on bad terms. They still control the 2FA. Recovering the account requires Instagram's glacially slow business verification process.

The rule

Every work tool must be accessed with a work account from your directory.

No exceptions. If someone says "I'll just use my personal email, it's easier," the answer is no. Create them a directory account. If the service doesn't support SSO, create the account with their work email address and store credentials in Passwork.

This applies to:

• All SaaS applications
• Social media accounts (create role-based emails like [email protected])
• Developer tools and platforms
• Vendor portals and partner accounts
• Domain registrars and DNS providers
• Everything

The short-term convenience of letting someone use a personal account isn't worth losing control of company data when they leave.

Types of user directories

Google Workspace

If you're already using Google Workspace for email, you have a user directory. Every Google Workspace user is in Google's directory service.

Pros:

• You're probably already paying for it
• Integrates with most SaaS applications
• Supports SAML and OIDC for SSO
• Good admin console for managing users

Cons:

• SSO (beyond Google apps) requires Business Starter or higher
• SAML apps require Business Plus or Enterprise ($18+/user/month)
• Limited advanced identity features

Best for: Companies already on Google Workspace who want to avoid adding another tool.

Microsoft 365 / Entra ID (Azure AD)

Microsoft's directory service, included with Microsoft 365 Business plans.

Pros:

• Included if you use Microsoft 365
• Deep integration with Windows, Office, and Azure
• Mature enterprise features
• Conditional access policies

Cons:

• More complex to administer than Google
• Advanced features require premium licenses
• Less intuitive for non-Microsoft environments

Best for: Companies using Microsoft 365 or Azure cloud.

Okta

Dedicated identity management platform — this is all they do.

Pros:

• Best-in-class SSO and identity features
• Huge app integration catalog
• Advanced security (adaptive MFA, device trust)
• Universal Directory works across providers

Cons:

• Expensive ($2-15/user/month depending on features)
• Overkill for small teams
• Another vendor to manage

Best for: Companies with complex identity needs or rapid growth plans.

JumpCloud

Cloud directory designed for smaller companies and distributed teams.

Pros:

• Free for up to 10 users
• Manages devices (Mac, Windows, Linux) plus cloud apps
• LDAP and RADIUS support
• Reasonable pricing ($7-15/user/month)

Cons:

• Smaller app catalog than Okta
• Less mature than Google/Microsoft
• Device management can be complex

Best for: Small teams that need device management bundled with identity.

Complete directory services list

From simplest to most complex, here's what's available in the market.

Tier 1: You probably already have it

These come bundled with services you're likely using. No extra cost, minimal setup.

Service	What you get	SSO support	Price	Best for
Google Workspace	Directory + email + docs	SAML (Business Plus+), OIDC	$6-18/user/mo	Gmail-based companies
Microsoft 365	Entra ID + Office	SAML, OIDC	$6-22/user/mo	Outlook/Windows shops
Zoho One	Directory + 40+ apps	SAML, OIDC	$37/user/mo	Zoho ecosystem users

Tier 2: Free or very cheap options

Good for startups and small teams watching their budget.

Service	What you get	Free tier	Paid price	Best for
JumpCloud	Cloud directory + MDM	10 users free	$7-15/user/mo	Small teams, remote-first
Authentik	Open source IdP	Self-hosted free	Enterprise support paid	Tech-savvy teams
Keycloak	Open source IdP	Free (self-host)	—	Developers, on-prem
Authelia	Open source SSO	Free (self-host)	—	Home lab, small infra
Kanidm	Modern open source IdP	Free (self-host)	—	Security-focused teams
FusionAuth	Developer identity	Free community	$125+/mo	Custom apps
Zitadel	Cloud-native IAM	Free tier	$100+/mo	Cloud-native startups

Tier 3: Mid-market identity providers

Dedicated identity platforms. More features than bundled options, less complex than enterprise.

Service	Key features	Price	Best for
OneLogin	SSO, MFA, directory	$4-8/user/mo	Growing companies
Duo Security (Cisco)	MFA-first, SSO	$3-9/user/mo	MFA-focused orgs
Passwork	Password & secrets manager with AD/LDAP, SAML SSO, passkey support	from €3/user/mo	Teams using Passwork as password manager
Rippling	HR + IT + identity	$8+/user/mo	HR-driven companies
WorkOS	SSO for B2B SaaS	Pay per connection	SaaS builders
Clerk	Developer auth	Free tier + $0.02/MAU	Developer-focused
Stytch	Passwordless auth	Free tier + paid	Modern apps
Descope	No-code auth flows	Free tier	Rapid development

Tier 4: Enterprise identity platforms

Full-featured platforms for complex requirements. Expensive but powerful.

Service	Key features	Price	Best for
Okta	Industry leader, 7000+ integrations	$2-15/user/mo	Enterprise SSO
Okta Customer Identity	B2C identity	Usage-based	Customer-facing apps
Microsoft Entra ID P1/P2	Conditional access, PIM	$6-9/user/mo	Azure enterprises
Ping Identity	Enterprise SSO, federation	Custom	Large enterprises
ForgeRock	Identity platform	Custom	Banking, healthcare
IBM Security Verify	Enterprise IAM	Custom	IBM shops
CyberArk Identity	Privileged + workforce	Custom	Security-first orgs
SailPoint	Identity governance	Custom	Compliance-heavy
Saviynt	Identity cloud	Custom	Enterprise GRC

Tier 5: Specialized and regional options

Niche solutions for specific use cases or regions.

Service	Focus	Best for
Frontegg	B2B SaaS user management	SaaS products
PropelAuth	B2B auth + orgs	Multi-tenant SaaS
Kinde	Modern auth	Startups, SMBs
SuperTokens	Open source auth	Self-hosted preference
Hanko	Passkey-first	Passwordless adoption
Ory	Open source identity	Cloud-native teams
Auth.js (NextAuth)	JavaScript auth	Next.js/Node apps
Logto	Open source CIAM	Customer identity
BoxyHQ	Enterprise SSO SAML	B2B SaaS

How to choose

Already using Google or Microsoft for email? → Start with their built-in directory. Upgrade plan if you need SAML SSO.

Budget under $5/user/month? → JumpCloud (10 users free), or self-hosted Authentik/Keycloak if you have the skills.

Need device management too? → JumpCloud, Rippling, or Microsoft Intune.

Building a SaaS product? → WorkOS, Clerk, or Auth0 for customer-facing auth.

Enterprise with complex compliance? → Okta, Ping Identity, or Microsoft Entra ID P2.

Want open source? → Keycloak (mature), Authentik (modern UI), or Ory (cloud-native).

What most small companies should do

1. If you use Google Workspace: Start there. Upgrade to Business Plus when you need SAML for more apps.
2. If you use Microsoft 365: Entra ID is already included. Use it.
3. If you use neither: JumpCloud is the best value for small teams.
4. If budget is zero: Keycloak or Authentik self-hosted, but expect to spend time on maintenance.

Don't over-engineer this. A working directory with 80% of your apps connected is better than a perfect directory that never gets deployed.

Why centralize all users in the directory

The temptation is to use directory SSO for some applications and create local accounts for others. Don't do this.

Create every user in the directory, even if:

• They only need access to one application
• The application doesn't support SSO
• It seems faster to just create a local account

Here's why:

Offboarding works: When someone leaves, you disable their directory account. They lose access to everything connected. No forgotten accounts.

Onboarding is consistent: New hire? Create one account, assign to groups, they get access to everything their role needs.

Audit trail exists: Who has access to what? Check the directory. No need to audit 50 separate applications.

Password policies apply: Password requirements, MFA enforcement — set once in the directory, applies everywhere.

For applications that don't support SSO: Create the user in the directory anyway for tracking. Use the password manager (Passwork) to manage the local account credentials. At least you have a central record.

Setting up a dedicated domain for identity

You can run your identity from your main domain (company.com), but many organizations use a dedicated subdomain or separate domain for identity purposes.

Options:

Approach	Example	Pros	Cons
Main domain	[email protected]	Simple, one domain	Everything tied together
Subdomain	[email protected]	Separation, still branded	Some apps handle poorly
Separate domain	[email protected]	Full isolation	Confusing for users

When a separate identity domain makes sense:

• You want to separate employee identity from customer-facing email
• You're using multiple identity providers
• Compliance requires separation of identity infrastructure
• You plan to change primary domains but keep identity stable

Practical recommendation: For most small companies, use your primary domain. The complexity of a separate domain isn't worth it until you have specific requirements.

How SSO works (the simple version)

When a user tries to access an SSO-connected application:

1. User goes to app.example.com
   ↓
2. App redirects to identity provider: "Who is this?"
   ↓
3. User authenticates with IdP (password + MFA)
   ↓
4. IdP sends signed assertion back to app: "This is [email protected], 
   member of engineering group"
   ↓
5. App grants access based on the assertion

Two main protocols handle this:

SAML 2.0 — Older, XML-based, widely supported by enterprise apps. Configuration involves exchanging certificates and metadata XML files.

OIDC (OpenID Connect) — Newer, JSON-based, simpler to implement. Built on OAuth 2.0. Preferred for modern applications.

Most applications support both. If you have a choice, OIDC is usually easier to configure.

Connecting applications to your directory

Step 1: Check what your directory supports

Google Workspace:

• Settings → Apps → Web and mobile apps → Add app → Search for SAML apps

Microsoft Entra ID:

• Azure Portal → Entra ID → Enterprise applications → New application

Step 2: Check application SSO support

Before you can connect an application, check:

1. Does it support SAML or OIDC?
2. What plan is required? (Many apps require paid tiers for SSO)
3. What information do you need to exchange?

Common patterns:

Application	SSO protocol	Required plan
Slack	SAML	Business+
GitHub	SAML	Enterprise
AWS	SAML	Free (IAM Identity Center)
Notion	SAML	Business
Figma	SAML	Organization
Atlassian (Jira/Confluence)	SAML	Premium
Salesforce	SAML	Included
Zoom	SAML	Business+
Passwork	SAML	Advanced

If you use Passwork as your password manager, you can connect it to your identity provider via SAML SSO — so employees sign into Passwork through the same centralized login as everything else. This is available in the Advanced plan.

The SSO tax: Many SaaS vendors charge more for SSO support. This is frustrating but real. Budget for it if SSO is important to you.

Step 3: Configure the connection

General process (varies by app):

On the application side:

1. Find SSO settings (usually Settings → Security or Admin → Authentication)
2. Choose SAML or OIDC
3. Get the callback/ACS URL and entity ID

On the directory side:

1. Add new application (SAML or OIDC)
2. Enter the callback URL and entity ID from the app
3. Download metadata or get IdP values (Entity ID, SSO URL, certificate)

Back on the application side:

1. Enter the IdP metadata or values
2. Configure attribute mapping (email, name, groups)
3. Test with a single user before enforcing

Step 4: Test and enforce

1. Test SSO login with one account
2. Verify user attributes pass correctly
3. Check group memberships work (if using group-based access)
4. Enable SSO for all users
5. Disable local authentication (optional but recommended for security)

Setting up automatic user provisioning (SCIM)

SSO handles authentication, but what about creating and removing users automatically?

SCIM (System for Cross-domain Identity Management) handles provisioning:

• New user added to directory → automatically created in connected apps
• User removed from directory → automatically deactivated in apps
• User changes groups → app permissions update automatically

Which apps support SCIM:

Application	SCIM support
Slack	Enterprise Grid only
GitHub	Enterprise Cloud
Salesforce	Yes
Okta-connected apps	Most
Google Workspace apps	Native

SCIM requires more setup than SSO but dramatically improves onboarding/offboarding automation.

Directory structure: groups and roles

Organize users into groups that map to access levels:

company.com
├── all-employees
├── engineering
│   ├── eng-backend
│   ├── eng-frontend
│   └── eng-devops
├── product
├── marketing
├── finance
└── admins
    ├── it-admins
    └── security-admins

Mapping groups to application access:

Group	Slack	GitHub	AWS	Jira
engineering	✓	✓ (write)	✓ (dev)	✓
marketing	✓	✓ (read)	—	✓ (view)
finance	✓	—	✓ (billing)	—
admins	✓	✓ (admin)	✓ (admin)	✓ (admin)

When a new engineer joins:

1. Create user in directory
2. Add to all-employees and engineering groups
3. SSO automatically grants access to Slack, GitHub, AWS, Jira

When they leave:

1. Disable directory account
2. All access revoked immediately

MFA enforcement through the directory

Configure MFA requirements in the directory, not in each application.

Google Workspace: Admin console → Security → 2-Step Verification → Enforcement

Microsoft Entra ID: Security → MFA → Additional cloud-based MFA settings

Best practice:

• Require MFA for all users
• Allow multiple methods (authenticator app, hardware keys)
• Provide recovery options (backup codes, admin reset)

When MFA is enforced at the directory level, users complete MFA once during SSO authentication, then access all connected applications without re-authenticating for each one.

Handling applications without SSO support

Not every application supports SSO. For these:

1. Still create users in directory for tracking
2. Use password manager (Passwork) to store credentials
3. Document the application in your SaaS inventory
4. Include in offboarding checklist for manual deactivation

Store the credentials in Passwork with clear naming:

• [AppName] - Admin account
• [AppName] - [email protected]

When someone leaves, the offboarding process includes:

1. Disable directory account (handles SSO apps)
2. Check Passwork for local accounts (handles non-SSO apps)
3. Deactivate those manually

Practical setup: Google Workspace as your directory

Here's a step-by-step for small companies starting with Google Workspace:

Prerequisites:

• Google Workspace Business Starter or higher
• Admin access to Google Admin console
• List of applications to connect

Step 1: Verify domain and users

Admin console → Users
- All employees should have Google Workspace accounts
- Verify email addresses match expected format

Step 2: Create organizational units and groups

Admin console → Directory → Organizational units
- Create structure: Engineering, Marketing, etc.

Admin console → Directory → Groups
- Create groups matching your access needs
- Add users to appropriate groups

Step 3: Enable SSO for first application (example: Slack)

On Slack side:

1. Workspace Settings → Authentication → Configure SSO
2. Copy the Slack ACS URL and note the workspace URL

On Google side:

1. Admin console → Apps → Web and mobile apps → Add app
2. Search for Slack or add custom SAML app
3. Enter Slack's ACS URL
4. Download Google's IdP metadata

Back on Slack:

1. Upload Google's metadata or enter values manually
2. Configure attribute mapping (email)
3. Test with one user
4. Enable for workspace

Step 4: Repeat for other applications

Work through your priority list:

1. AWS (IAM Identity Center)
2. GitHub (if Enterprise)
3. Other critical applications

Step 5: Document and communicate

• Update SaaS inventory with SSO status
• Inform users about SSO login changes
• Update onboarding/offboarding procedures

Common mistakes

Mistake 1: Shadow accounts

Users create local accounts in applications instead of using SSO. They bypass the directory and you lose control.

Fix: After enabling SSO, disable local authentication where possible. Make SSO the only way in.

Mistake 2: Incomplete group mapping

Groups exist in directory but aren't mapped to application permissions. Users get SSO access but wrong permission levels.

Fix: Document group-to-permission mapping for each application. Test with users from each group.

Mistake 3: No break-glass accounts

Everyone uses SSO. Directory has an outage. Nobody can access anything, including the directory admin console.

Fix: Keep one or two local admin accounts for emergency access. Store credentials in Passwork and test them quarterly.

Mistake 4: Ignoring non-SSO apps

Focus goes to SSO apps. Non-SSO applications are forgotten, with stale accounts remaining after offboarding.

Fix: Include non-SSO apps in your SaaS inventory and offboarding checklist.

Workshop: set up your user directory

Block 3-4 hours for initial setup. This is foundational work that will save you countless hours on onboarding and offboarding.

Part 1: Choose and configure your directory (45 minutes)

If you already have Google Workspace or Microsoft 365:

1. Log into admin console
2. Verify all current employees have accounts
3. Check that no former employees still have active accounts
4. Review current password and MFA policies

If starting fresh:

1. Compare options from the directory services list above
2. Sign up for chosen service (JumpCloud free tier is good for testing)
3. Configure basic settings (domain, password policy)
4. Create your admin account with MFA enabled

Deliverable: Directory service chosen and admin access confirmed

Part 2: Create your organizational structure (30 minutes)

1. Create organizational units or groups:

   ├── all-employees
   ├── engineering
   ├── product
   ├── marketing
   ├── finance
   └── admins

2. Document what each group should have access to:

   Group	Slack	GitHub	AWS	Jira	CRM
   engineering	✓	✓ (write)	✓ (dev)	✓	—
   product	✓	✓ (read)	—	✓	✓
   marketing	✓	—	—	✓ (view)	✓

3. Add yourself to appropriate groups for testing

Deliverable: Group structure created and documented

Part 3: Connect your first SSO application (45 minutes)

Pick one application that supports SSO and is business-critical. Good first choices:

• Passwork (Advanced plan) — your password manager is the single point of access to all credentials; connecting it to SSO means employees use one centralized login for everything, and offboarding revokes access to Passwork along with everything else
• AWS (IAM Identity Center) — critical infrastructure
• Slack (Business+ required) — everyone uses it
• GitHub (Enterprise required) — important for devs

Steps:

1. Check the application's SSO documentation
2. In your directory, add a new SAML or OIDC application
3. Exchange metadata/configuration between directory and app
4. Test SSO login with your account
5. Document the configuration

Deliverable: One application connected via SSO, tested and working

Part 4: Migrate existing users (30 minutes)

1. Export list of users from the connected application
2. Verify each user exists in your directory
3. Create missing directory accounts
4. Test SSO access for one or two users
5. Plan rollout communication to team

Deliverable: User mapping documented, migration plan created

Part 5: Set up emergency access (15 minutes)

1. Create a break-glass local admin account in critical applications
2. Generate a strong password, store in Passwork
3. Document which applications have emergency accounts
4. Test emergency access works

Deliverable: Emergency access configured and tested

Part 6: Document onboarding/offboarding (30 minutes)

Create or update your procedures:

Onboarding checklist:

☐ Create account in [directory name]
☐ Add to appropriate groups: ___________
☐ Verify SSO access to critical apps
☐ Create local accounts for non-SSO apps (store in Passwork)
☐ Send welcome email with login instructions

Offboarding checklist:

☐ Disable account in [directory name] (handles all SSO apps)
☐ Check Passwork for non-SSO app credentials
☐ Deactivate non-SSO accounts manually:
   ☐ [App 1]
   ☐ [App 2]
☐ Transfer ownership of shared resources
☐ Confirm no access remains

Deliverable: Onboarding and offboarding checklists ready to use

Part 7: Connect two more applications (60 minutes)

Repeat Part 3 for two more critical applications. By the end, you should have at least three apps using SSO.

Priority order:

1. Email/productivity (already covered if using Google/Microsoft as directory)
2. Cloud infrastructure (AWS, GCP, Azure)
3. Code repository (GitHub, GitLab)
4. Communication (Slack, Teams)
5. Project management (Jira, Asana, Linear)

Deliverable: Three applications connected via SSO

Workshop summary

After completing this workshop, you should have:

• Directory service configured with your domain
• Group structure matching your organization
• At least 3 applications connected via SSO
• Emergency access accounts documented
• Onboarding/offboarding checklists created
• Migration plan for remaining users

Time investment: ~4 hours now, saves 30+ minutes per hire/departure forever.

Self-check: is your directory ready?

Directory basics

• Chosen a primary directory (Google Workspace, Microsoft 365, etc.)
• All employees have accounts in the directory
• Group structure created (departments, roles)
• MFA enforced for all users

SSO connections

• Identified which applications support SSO
• Connected at least 3 critical applications via SSO
• Tested SSO login works correctly
• Local authentication disabled where possible

Provisioning and access

• Onboarding creates directory account first
• Group membership determines application access
• Offboarding disables directory account immediately
• Non-SSO applications tracked separately

Emergency access

• Break-glass local admin accounts exist
• Emergency credentials stored in Passwork
• Tested emergency access within last quarter

If you can check off at least 10 of these 14 items, your directory foundation is solid.

Talking to leadership

If someone asks why you spent time on this:

"We centralized user management into a single directory with SSO. Now when someone joins, they get access to everything they need through one account. When they leave, we disable that account and they lose access everywhere instantly. No more forgotten accounts in random applications, no more orphaned access. It also means stronger security — we can enforce MFA and password policies in one place."

Short version: "One account per person, one place to manage access. When someone leaves, we flip one switch and they're locked out of everything."

What's next

You now have:

• Password manager and MFA (previous chapter)
• Centralized user directory with SSO

Next chapter: SaaS inventory and access management — discovering all the applications your company uses and mapping who has access to what.