Authentication setup - Mintlify

Authentication requires users to log in before accessing your documentation. When you enable authentication, users must log in to access any content. You can configure specific pages or groups as public while keeping other pages protected.

Configure authentication

Select the handshake method that you want to configure.

Prerequisites

  • Your security requirements allow sharing passwords among users.

Set up

Example

You host your documentation at docs.foo.com and you need basic access control without tracking individual users. You want to prevent public access while keeping setup simple.Create a strong password in your dashboard. Share credentials with authorized users.

Prerequisites

  • Everyone who needs to access your documentation must be a member of your Mintlify organization.

Set up

Example

You host your documentation at docs.foo.com and your entire team has access to your dashboard. You want to restrict access to team members only.Enable Mintlify authentication in your dashboard settings.Verify team access by checking that all team members are active in your organization.

Prerequisites

  • An OAuth or OIDC server that supports the Authorization Code Flow.
  • Ability to create an API endpoint accessible by OAuth access tokens (optional, to enable group-based access control).

Set up

Example

You host your documentation at foo.com/docs and you have an existing OAuth server at auth.foo.com that supports the Authorization Code Flow.Configure your OAuth server details in your dashboard:

  • Authorization URL: https://auth.foo.com/authorization
  • Client ID: ydybo4SD8PR73vzWWd6S0ObH
  • Scopes: ['provider.users.docs']
  • Token URL: https://auth.foo.com/exchange
  • Info API URL: https://api.foo.com/docs/user-info
  • Logout URL: https://auth.foo.com/logout?returnTo=https%3A%2F%2Ffoo.com%2Fdocs

Create a user info endpoint at api.foo.com/docs/user-info, which requires an OAuth access token with the provider.users.docs scope, and returns:

{
  "groups": ["engineering", "admin"],
  "expiresAt": 1735689600,
  "apiPlaygroundInputs": {
    "header": {
      "Authorization": "Bearer user_abc123"
    }
  }
}

Configure your OAuth server to allow redirects to your callback URL.

Prerequisites

  • An authentication system that can generate and sign JWTs.
  • A backend service that can create redirect URLs.

Set up

Example

You host your documentation at docs.foo.com with an existing authentication system at foo.com. You want to extend your login flow to grant access to the docs while keeping your docs separate from your dashboard (or you don’t have a dashboard).Create a login endpoint at https://foo.com/docs-login that extends your existing authentication.After verifying user credentials:

  • Generate a JWT with user data in Mintlify’s format.
  • Sign the JWT and redirect to https://docs.foo.com/login/jwt-callback#{SIGNED_JWT}.

Redirect unauthenticated users

When an unauthenticated user tries to access a protected page, the redirect to your login URL preserves the user’s intended destination.

  1. User attempts to visit a protected page: https://docs.foo.com/quickstart.
  2. Redirect to your login URL with a redirect query parameter: https://foo.com/docs-login?redirect=%2Fquickstart.
  3. After authentication, redirect to https://docs.foo.com/login/jwt-callback?redirect=%2Fquickstart#{SIGNED_JWT}.
  4. User lands in their original destination.

Make pages public

When using authentication, all pages require authentication to access by default. You can make specific pages viewable without authentication at the page or group level with the public property.

Individual pages

To make a page public, add public: true to the page’s frontmatter.

---
title: "Public page"
public: true
---

Groups of pages

To make all pages in a group public, add "public": true beneath the group’s name in the navigation object of your docs.json.

{
  "navigation": {
    "groups": [
      {
        "group": "Public group",
        "public": true,
        "icon": "play",
        "pages": [
          "quickstart",
          "installation",
          "settings"
        ]
      },
      {
        "group": "Private group",
        "icon": "pause",
        "pages": [
          "private-information",
          "secret-settings"
        ]
      }
    ]
  }
}

Control access with groups

When you use OAuth or JWT authentication, you can restrict specific pages to certain user groups. This is useful when you want different users to see different content based on their role or attributes. Manage groups through user data passed during authentication. See User data format for details.

{
  "groups": ["admin", "beta-users"],
  "expiresAt": 1735689600
}

Specify which groups can access specific pages using the groups property in frontmatter.

Example page restricted to the admin group

---
title: "Admin dashboard"
groups: ["admin"]
---

Users must belong to at least one of the listed groups to access the page. If a user tries to access a page without the required group, they’ll receive a 404 error.

How groups interact with public pages

  • All pages require authentication by default.
  • Pages with a groups property are only accessible to authenticated users in those groups.
  • Pages without a groups property are accessible to all authenticated users.
  • Pages with public: true and no groups property are accessible to everyone.

User data format

When using OAuth or JWT authentication, your system returns user data that controls session length, group membership, and content personalization.

Session expiration time in seconds since epoch. When the current time passes this value, the user must re-authenticate.

List of groups the user belongs to. Pages with matching groups in their frontmatter are accessible to this user.Example: A user with groups: ["admin", "engineering"] can access pages tagged with either the admin or engineering groups.

Pre-fills API playground fields with user-specific values. When a user authenticates, these values populate the corresponding input fields in the API playground. Users can override pre-filled values, and their overrides persist in local storage.Only values that match the current endpoint’s security scheme are applied.

Header values to pre-fill, keyed by header name.

Query parameter values to pre-fill, keyed by parameter name.

Cookie values to pre-fill, keyed by cookie name.

Server variable values to pre-fill, keyed by variable name.

Path parameter values to pre-fill, keyed by parameter name.