Single Sign-On (SSO) lets your team members and readers log in to Document360 using credentials from your existing identity provider (IdP), such as Okta, Microsoft Entra, or Google Workspace. Instead of managing separate passwords for Document360, users authenticate once through your IdP and get access automatically. Document360 supports SAML, OpenID Connect, and JWT as SSO methods, and SCIM for automated user provisioning.
What is SSO?
Single Sign-On (SSO) is an authentication method that lets a user log in once and access multiple applications without entering credentials again for each one.
In Document360, SSO works between two parties:
- Identity Provider (IdP): The service that stores and verifies your users' credentials. Examples include Okta, Microsoft Entra ID, Google Workspace, ADFS, and OneLogin.
- Service Provider (SP): Document360, which relies on the IdP to confirm a user's identity before granting access.
When a user signs in, the IdP authenticates them and sends a verified token to Document360. Document360 trusts that token and grants access without requiring a separate password.
Document360 supports multiple simultaneous SSO configurations. You can use one IdP for your internal team and a different one for external readers, giving each audience a login experience that fits your setup.
Why use SSO in Document360?
| Benefit | What it means in practice |
|---|---|
| Improved security | Credentials are managed centrally in your IdP, reducing the risk of weak or reused passwords in Document360 |
| Simplified access | Users sign in once and access Document360 without a separate login |
| Easier user management | Add or remove access from your IdP and it reflects in Document360 automatically (with SCIM) |
| Compliance support | Centralized authentication helps meet regulatory requirements for access control |
| Reduced IT overhead | Fewer password resets and no separate credential database to manage |
Supported SSO methods
Document360 supports three SSO meth ods. Each works differently and suits different use cases.
SAML 2.0
An XML-based standard used by most enterprise identity providers. Best for organizations that already use Okta, Microsoft Entra, Google Workspace, ADFS, or OneLogin. Supports both team and reader authentication.
Go to SAML →OpenID Connect (OIDC)
A modern authentication protocol built on OAuth 2.0. Suitable for organizations using Okta, Auth0, or ADFS with OpenID support. Supports both team and reader authentication.
Go to OpenID Connect →JWT (JSON Web Token)
A developer-implemented method for authenticating readers from your own application. No external IdP required. Best when you manage authentication in your own system and want to pass verified tokens to Document360.
Go to JWT →Choosing the right SSO method
| SAML | OpenID Connect | JWT | |
|---|---|---|---|
| Best for | Enterprises with an existing IdP | Organizations using OAuth 2.0-based providers | Developers managing authentication in their own application |
| Authenticates | Users and readers | Users and readers | Readers only |
| Requires an IdP | Yes | Yes | No |
| Setup complexity | Medium | Medium | Higher (requires custom development) |
| SCIM provisioning | Supported (Okta, Entra, OneLogin, ADFS, others) | Supported (Okta, ADFS, others) | Not applicable |
| Can coexist with other methods | Yes, SAML and JWT can be active together | Yes, OIDC and JWT can be active together | Yes |
SAML and OpenID Connect are mutually exclusive. You cannot have both active in the same project at the same time. However, either SAML or OpenID Connect can coexist with JWT in the same project.
SCIM provisioning
SCIM (System for Cross-domain Identity Management) is a provisioning layer that works on top of your SSO configuration to automate user lifecycle management.
With SCIM enabled, any change you make in your IdP (adding a user, updating a role, deactivating someone) is reflected in Document360 automatically. You do not need to manage user accounts manually in Document360.
SCIM must be configured after your SSO setup is complete. It is available for SAML and OpenID Connect configurations with supported providers.
Learn about SCIM provisioning →
How SSO works
When a user signs in to Document360 using SSO, the following happens:
- The user opens the Document360 portal or knowledge base site and enters their email or domain.
- Document360 identifies the SSO configuration for that domain and redirects the user to the IdP login page.
- The user enters their credentials in the IdP (not in Document360).
- The IdP verifies the credentials and sends a signed token back to Document360.
- Document360 validates the token and grants the user access based on their assigned role and permissions.
The user is now logged in. If they access other applications covered by the same SSO session, they do not need to log in again.
Get started with SSO
Configure OpenID Connect
Set up SSO using OpenID Connect with your identity provider.
OpenID Connect overview →Manage SSO access
Add users, manage readers, map projects, and control login settings after SSO is configured.
Managing access with SSO →
Can I use SAML and OpenID Connect at the same time?
No. SAML and OpenID Connect are mutually exclusive in Document360. You can only have one active at a time per project. However, either one can coexist with a JWT configuration in the same project.
Can I configure SSO for both my team and my readers?
Yes. SAML and OpenID Connect support authentication for both team members (who access the knowledge base portal) and readers (who access the knowledge base site). JWT is for reader authentication only and cannot be used to log in to the portal.
Can I set up multiple SSO configurations in the same project?
Yes. Document360 supports multiple simultaneous SSO configurations. For example, you can use one IdP for internal employees and a separate IdP for external readers. You can also have up to 5 JWT configurations active in the same project alongside a SAML or OpenID Connect configuration.