Authentication
Enterprise feature
This feature is available only for the Enterprise plan. To get started, reach out to support@buildwithfern.com.
Self-hosted Fern documentation supports authentication via environment variables set in your Dockerfile. When no auth environment variables are configured, your docs are fully public.
Two authentication modes are available:
- Password authentication - Simple shared-password protection
- Basic token verification - JWT-based authentication with a custom login flow
Password authentication
Password authentication protects your docs behind a simple password prompt. Users must enter the correct password to view the documentation.
Add the following environment variables to your Dockerfile:
Replace <YOUR PASSWORD> with the password users will enter to access the docs.
When a user visits the documentation, they are redirected to a login page where they must enter the password. After entering the correct password, they can browse the docs freely.
Basic token verification
Basic token verification uses JWTs (JSON Web Tokens) to authenticate users. This is useful when you want to integrate your docs with an existing authentication system, such as your own login portal.
How it works
- An unauthenticated user visits the docs and is redirected to your login page (
FERN_AUTH_REDIRECT). - Your login page authenticates the user (e.g., checking credentials against your database).
- After successful authentication, your server creates a signed JWT using the shared secret.
- Your server sends the user to the Fern callback endpoint (
/api/fern-docs/auth/jwt/callback) with the JWT. This can be done via a GET redirect with the token as a query parameter, or via a POST request with the token in anapplication/x-www-form-urlencodedbody. - The Fern docs container verifies the JWT signature and issuer, sets a session cookie, and redirects the user to the docs.
Configuration
Add the following environment variables to your Dockerfile:
Building your login server
Your login server is responsible for authenticating users and redirecting them back to the docs with a signed JWT.
When the Fern container redirects an unauthenticated user, it appends the following query parameters to FERN_AUTH_REDIRECT:
redirect_uri- The callback URL on the Fern docs container (e.g.,https://docs.example.com/api/fern-docs/auth/jwt/callback)state- The page the user was trying to access
Your server must:
- Authenticate the user.
- Create a JWT signed with the same
FERN_AUTH_SECRETusing the HS256 algorithm. - Send the user to the
redirect_uriwith the JWT asfern_tokenand the originalstateas the return-to path. You can use either method:- GET redirect: Append
fern_tokenandstateas query parameters. - POST form submission: Submit
fern_tokenandstateasapplication/x-www-form-urlencodedfields. POST avoids exposing the token in URLs and server logs.
- GET redirect: Append
The JWT payload must include the following claims:
Here is an example Node.js (Express) server that signs a JWT and redirects to the callback:
GET (query parameters)
POST (form body)
The FERN_AUTH_SECRET in your login server must exactly match the secret set in the Dockerfile. If they differ, JWT verification will fail and users will not be able to log in.
Testing with the built-in test login page
The self-hosted container includes a built-in test login page that you can enable for development and testing. This lets you verify the authentication flow without building your own login server.
Add the following environment variables to your Dockerfile:
Setting FERN_AUTH_TEST_LOGIN="true" enables the /__test-login endpoint on the container. When FERN_AUTH_REDIRECT points to this endpoint, unauthenticated users see a test login page with a single “Login with Test” button. Clicking the button mints a valid JWT and completes the authentication flow.
The test login page is intended for development and testing only. Do not enable FERN_AUTH_TEST_LOGIN in production environments.
Page-level access control
By default, all pages require authentication when auth is enabled. Use FERN_AUTH_ALLOWLIST and FERN_AUTH_DENYLIST to control which pages require login. Both accept comma-separated regex patterns matched against page paths.
For example, to make all pages publicly accessible:
To make only API Reference pages require login:
API key injection
You can enable API key injection in the API Explorer for self-hosted deployments. This shows a Login button in the API Explorer so users can authenticate and have their API keys auto-populated, without requiring login for the entire documentation site.
Add FERN_API_KEY_INJECTION_ENABLED to your Dockerfile alongside the basic token verification variables:
With FERN_AUTH_ALLOWLIST="/(.*)", all doc pages are publicly accessible (no login wall), but the API Explorer still shows the Login button. When a user logs in, their JWT’s fern payload is read and the API key is injected into the API Explorer. See Autopopulate API keys for the full fern payload reference.