dotAuth

Description

dotAuth is the single sign-on (SSO) feature built into dotCMS. People sign in to dotCMS through your organization's identity provider - Okta, Microsoft Entra ID, Google Workspace, Auth0, Keycloak, Ping, or ADFS - instead of separate dotCMS passwords, and headless front ends can call dotCMS APIs as the signed-in user, so each visitor sees only the content their roles allow.

dotAuth supports OpenID Connect (OIDC) and OAuth 2.0, SAML 2.0, and headless token exchange, which turns an identity-provider token into a short-lived dotCMS session reference for REST and GraphQL calls.

You set it up under Settings > dotAuth, with a guided screen for each protocol. It is available in dotCMS 26.08.24-01 and later and replaces the legacy dotCMS OAuth plugin. If you use the plugin today, re-enter its configuration in dotAuth; the plugin can keep running until you switch.

Benefits

• Sign in with the credentials people already have. One corporate login replaces a separate dotCMS password for every user, so there is nothing new to remember, reset, or manage, and your identity provider's multi-factor authentication applies automatically.

• Accounts that create themselves. A user's dotCMS account is created the first time they sign in, so onboarding no longer waits on an administrator and nobody has to build accounts by hand.

• Access that follows your directory. Identity-provider groups map to dotCMS roles and are refreshed at every sign-in, so people get the right permissions when they join or change teams, and removing someone at the identity provider stops new sign-ins.

• Security you don't have to build. PKCE, token signature checks, replay protection, signed SAML responses by default, and encrypted client secrets are included, which gives you strong defaults and fewer questions in a security review.

• One setup, with exceptions only where you need them. Configure a System default once, then give any site its own identity provider and protocol, such as Okta for a partner portal and Entra ID for the intranet, all on one instance.

• Sign-in for single-page apps and headless sites made simple. Exchange an identity-provider token for a dotCMS session with no proxy, shared API key, or custom user-mapping code, and dotCMS permissions decide what each signed-in user can see.

• Roll out and move with confidence. Export and import your configuration between environments with password protection, and keep native login available as an administrator fallback, so turning on SSO never locks anyone out.

Use Cases

Corporate sign-in for the authoring team
An enterprise on Okta points dotCMS at its Okta tenant, maps the marketing-editors group to an editor role, and every author signs in with company credentials - no separate passwords for 50 or more content creators.

A different identity provider per site
A partner portal signs in through Okta while the employee intranet uses Entra ID, both on one dotCMS instance, each site with its own override.

A permission-aware headless intranet
A Next.js intranet signs employees in through the company identity provider and exchanges the token for a session reference. dotCMS permissions then decide which pages, files, and content each employee can see.

Satisfy an enterprise security review
Replace unmanaged local accounts with identity-provider-managed access, so onboarding and offboarding follow the directory the security team already controls.

Resources

• Documentation