Skip to main content

​
What is Single Sign-On?

Single Sign-On (SSO) allows your organization members to sign in to Documenso using your organization’s identity provider instead of managing separate Documenso passwords.

​
Benefits of SSO

​
Security

  • Centralized Authentication: One place to manage user access
  • Stronger Security: Leverage your existing security infrastructure
  • Quick Revocation: Immediately revoke access when employees leave
  • Compliance: Meet regulatory requirements for authentication
  • MFA Support: Inherit multi-factor authentication from your IdP

​
User Experience

  • Single Credentials: No need to remember another password
  • Faster Login: Seamless authentication if already logged in
  • Reduced Password Fatigue: One less password to manage
  • Automatic Provisioning: Users join organization automatically

​
Administration

  • Centralized Management: Manage users in one place
  • Auto-Provisioning: Automatically create accounts for new users
  • Domain-Based Access: Automatically add users from your domains
  • Audit Trail: Track authentication through your IdP
SSO is an enterprise feature and may require a specific subscription plan. Contact your administrator or Documenso support for availability.

​
Supported SSO Providers

Documenso supports SSO via:

​
OIDC (OpenID Connect)

The primary SSO method:
  • Compatible with most modern identity providers
  • Standards-based authentication
  • Supports popular providers like:
    • Okta
    • Auth0
    • Azure AD / Microsoft Entra ID
    • Google Workspace
    • OneLogin
    • Keycloak
    • Any OIDC-compliant provider

​
Prerequisites

Before configuring SSO:
  • Organization admin access in Documenso
  • Access to your identity provider’s admin console
  • Your organization’s domain verified in Documenso (if using domain-based auto-join)
  • OIDC provider details (Client ID, Client Secret, Well-Known URL)

​
Configuring SSO

1

Access SSO Settings

Navigate to your organization settings and click on SSO or Single Sign-On.
2

Enable SSO

Toggle the Enable SSO switch to turn on SSO for your organization.
3

Configure Provider

Enter your OIDC provider details:
  • Well-Known URL
  • Client ID
  • Client Secret (if updating)
4

Set Auto-Provisioning

Configure:
  • Auto-provision users (recommended)
  • Default organization role for new users
  • Allowed domains (optional)
5

Test SSO

Test the SSO configuration before rolling out to all users.
6

Save Settings

Save your SSO configuration.

​
SSO Configuration Fields

​
Well-Known URL

The OIDC discovery endpoint:
  • Format: https://your-provider.com/.well-known/openid-configuration
  • Provides configuration details to Documenso
  • Obtained from your identity provider
Examples:
  • Okta: https://your-domain.okta.com/.well-known/openid-configuration
  • Auth0: https://your-domain.auth0.com/.well-known/openid-configuration
  • Azure AD: https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration

​
Client ID

Your application’s client identifier:
  • Obtained when registering Documenso with your IdP
  • Unique identifier for your organization
  • Public value (not secret)

​
Client Secret

Your application’s client secret:
  • Obtained when registering Documenso with your IdP
  • Keep this value secure
  • Required for authentication
  • Only shown when creating/updating
The Client Secret is sensitive. Store it securely and never share it publicly. Treat it like a password.

​
Auto-Provision Users

Automatically create accounts:
  • Enabled: New users are automatically added to your organization
  • Disabled: Users must be manually invited
  • Recommended for most organizations

​
Default Organization Role

Role assigned to auto-provisioned users:
  • Admin: Full administrative access (not recommended for auto-provision)
  • Manager: Management capabilities
  • Member: Standard user access (recommended default)
Choose the most restrictive role that makes sense for your organization.

​
Allowed Domains

Restrict which email domains can auto-join:
  • Leave empty to allow all domains
  • Enter specific domains to restrict access
  • Separate multiple domains with spaces
  • Example: company.com subsidiary.com
Allowed domains provide additional security by ensuring only users from your organization’s email domains can auto-provision accounts.

​
Setting Up Your Identity Provider

General steps to configure your IdP:

​
1. Register Documenso as an Application

In your identity provider:
  1. Create a new OIDC application
  2. Name it “Documenso” or similar
  3. Note the assigned Client ID
  4. Generate or note the Client Secret

​
2. Configure Redirect URLs

Set the callback/redirect URL: 
https://your-documenso-domain.com/api/auth/callback/oidc
For Documenso Cloud: 
https://app.documenso.com/api/auth/callback/oidc

​
3. Configure Scopes

Request these OIDC scopes:
  • openid (required)
  • email (required)
  • profile (recommended)

​
4. Note Well-Known URL

Find your provider’s OIDC discovery endpoint (well-known URL).

​
5. Assign Users

Assign users or groups who should have access to Documenso.

​
Provider-Specific Guides

​
Okta

  1. Go to Applications > Applications in Okta
  2. Click Create App Integration
  3. Choose OIDC - OpenID Connect
  4. Choose Web Application
  5. Set redirect URI: https://your-domain/api/auth/callback/oidc
  6. Save and note Client ID and Client Secret
  7. Well-Known URL: https://your-domain.okta.com/.well-known/openid-configuration

​
Azure AD / Microsoft Entra ID

  1. Go to Azure Active Directory > App registrations
  2. Click New registration
  3. Name: “Documenso”
  4. Redirect URI: https://your-domain/api/auth/callback/oidc
  5. Register the application
  6. Note the Application (client) ID
  7. Go to Certificates & secrets > create new client secret
  8. Well-Known URL: https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration

​
Google Workspace

  1. Go to Google Cloud Console
  2. Create or select a project
  3. Enable Google+ API
  4. Go to Credentials > Create Credentials > OAuth client ID
  5. Application type: Web application
  6. Add authorized redirect URI: https://your-domain/api/auth/callback/oidc
  7. Note Client ID and Client Secret
  8. Well-Known URL: https://accounts.google.com/.well-known/openid-configuration

​
Auth0

  1. Go to Applications in Auth0 dashboard
  2. Click Create Application
  3. Choose Regular Web Application
  4. Go to Settings tab
  5. Add Callback URL: https://your-domain/api/auth/callback/oidc
  6. Note Client ID and Client Secret
  7. Well-Known URL: https://your-domain.auth0.com/.well-known/openid-configuration

​
Testing SSO Configuration

​
Before Rolling Out

1

Test Account

Use a test account to verify SSO login works.
2

Verify Auto-Provisioning

Test that new users are automatically added with correct roles.
3

Test Access

Confirm users can access organization teams and resources.
4

Check Audit Logs

Verify SSO events appear in security audit logs.

​
Testing Procedure

  1. Log out of Documenso completely
  2. Go to your organization’s login page: /o/your-org/signin
  3. Click Sign in with SSO (if shown)
  4. You should be redirected to your IdP
  5. Sign in with IdP credentials
  6. You should be redirected back to Documenso and signed in

​
Organization Login Page

With SSO enabled, your organization gets a custom login page: URL Format: /o/your-org-url/signin This page:
  • Shows your organization’s branding
  • Provides SSO login button
  • May still offer email/password option (based on settings)
  • Can be shared with organization members

​
User Experience

​
First-Time SSO Login

  1. User goes to organization login page
  2. Clicks “Sign in with SSO”
  3. Redirected to identity provider
  4. Signs in with IdP credentials
  5. Redirected back to Documenso
  6. Account auto-created (if auto-provisioning enabled)
  7. User added to organization with default role

​
Subsequent Logins

  1. User goes to organization login page
  2. Clicks “Sign in with SSO”
  3. If already authenticated with IdP, immediately signed in
  4. Otherwise, signs in with IdP credentials
  5. Redirected back to Documenso

​
Managing SSO Users

​
Viewing SSO Users

Identify users who authenticated via SSO:
  • Check user accounts in organization members
  • Review security audit logs for SSO sign-in events
  • Users will have SSO provider indicated in their account

​
Removing SSO Users

To remove a user’s access: Option 1: Remove from Documenso
  1. Go to organization members
  2. Remove the user
  3. They lose access to Documenso
Option 2: Remove from IdP (Recommended)
  1. Remove user’s access in your identity provider
  2. They can no longer authenticate via SSO
  3. Existing sessions may remain until expiry
Option 3: Both
  • Remove from both for immediate and permanent revocation

​
Troubleshooting

​
SSO Login Failed

Possible Causes:
  • Incorrect Well-Known URL
  • Invalid Client ID or Secret
  • Redirect URI not configured in IdP
  • User not assigned to application in IdP
  • OIDC scopes not properly configured
Solutions:
  • Verify all configuration values
  • Check IdP application settings
  • Review IdP logs for errors
  • Test with different user

​
Auto-Provisioning Not Working

Possible Causes:
  • Auto-provisioning disabled
  • User’s email domain not in allowed domains
  • IdP not providing email claim
  • User already exists with different auth method
Solutions:
  • Enable auto-provisioning in settings
  • Check allowed domains configuration
  • Verify IdP returns email in claims
  • Check for existing accounts

​
Redirect Loop

Possible Causes:
  • Incorrect redirect URI configuration
  • Browser cookie issues
  • Session problems
Solutions:
  • Verify redirect URI matches exactly
  • Clear browser cookies
  • Try different browser
  • Check for browser extensions blocking cookies

​
Users Can’t Access Organization

Possible Causes:
  • Auto-provisioning disabled and user not manually added
  • Insufficient permissions in default role
  • User not assigned to teams
Solutions:
  • Enable auto-provisioning or manually add users
  • Verify default role has necessary permissions
  • Assign users to appropriate teams

​
Security Best Practices

​
Configuration

  • Use HTTPS: Always use secure connections
  • Secure Client Secret: Store securely, never commit to repositories
  • Regular Rotation: Rotate client secrets periodically
  • Minimal Scopes: Only request necessary OIDC scopes

​
Access Control

  • Least Privilege: Use most restrictive default role
  • Domain Restrictions: Use allowed domains to limit access
  • Regular Audits: Review organization members regularly
  • MFA Required: Require MFA at IdP level

​
Monitoring

  • Audit Logs: Review security audit logs regularly
  • Failed Attempts: Monitor failed SSO attempts
  • Unusual Activity: Watch for suspicious sign-in patterns
  • Access Reviews: Quarterly access reviews

​
Disabling SSO

To disable SSO:
Disabling SSO will prevent users from signing in via SSO. Ensure they have alternative authentication methods (password, other SSO providers) before disabling.
  1. Go to organization SSO settings
  2. Toggle Enable SSO to off
  3. Confirm the change
  4. Users must use alternative sign-in methods

​
Next Steps

Build docs developers (and LLMs) love

Get started for freeTalk to us