Set Up Authentik as a Self-Hosted Single Sign-On Provider

Why Self-Hosted SSO Makes Sense

Single sign-on authentication is no longer a feature reserved for enterprise IT departments with dedicated security teams. With tools like Authentik, anyone running a self-hosted stack can set up a fully functional identity provider that handles login across multiple applications from one central dashboard. One login, one session, one place to revoke access – whether that’s for a home lab or a small team sharing internal services.

Authentik is an open-source identity provider written in Python and Go, offering support for OAuth2, OpenID Connect, SAML, LDAP, and SCIM. It ships with a clean web UI, a policy engine for fine-grained access control, and built-in support for multi-factor authentication including TOTP, WebAuthn, and static tokens. If you’re already running services like Dasherr, Gotify, or any other self-hosted tool behind a reverse proxy, centralizing authentication through Authentik removes the need to manage separate user accounts per service.

Prerequisites and Environment Setup

Before installing Authentik, you’ll need Docker and Docker Compose available on the host machine. Authentik’s recommended deployment method uses a pre-built Compose file that includes all required services: the Authentik server, the worker process, PostgreSQL, and Redis. The server handles web traffic and the API, while the worker processes background tasks like email delivery, flow execution, and scheduled jobs. Both containers need to be running for the system to function correctly.

You’ll also want a domain name or subdomain pointing to your server – something like auth.yourdomain.com. Authentik needs to be accessible over HTTPS, both for security and because several OAuth2 flows will reject plain HTTP redirect URIs. A reverse proxy like Nginx Proxy Manager, Caddy, or Traefik can handle TLS termination cleanly. If you’re running a local-only setup, a self-signed certificate with a custom CA works, but expect to manually trust that CA on each client device.

Installing Authentik with Docker Compose

Authentik provides an official docker-compose.yml file at goauthentik.io/docs/installation. Download it along with the accompanying .env file template. The environment file is where you set your PostgreSQL password, a secret key for session signing, and your email relay configuration if you want password reset emails to work. Generate the secret key with a tool like openssl rand -base64 36 – don’t skip this step or leave the placeholder value in place.

Once the environment variables are configured, run docker compose pull followed by docker compose up -d. The first startup takes a minute or two as Authentik applies database migrations. After the containers settle, the setup wizard is available at https://your-domain/if/flow/initial-setup/. This is a one-time step where you create the initial admin account. If you miss this URL or the wizard has already run, you can reset the admin password by exec-ing into the server container and running the ak create_recovery_key management command.

Once inside the admin interface, take a moment to explore the left sidebar. Authentik organizes configuration into Applications, Providers, Sources, Flows, and Outposts. The relationship between Providers and Applications is important: a Provider defines the authentication protocol and settings, while an Application is the front-facing object your users actually access. Every app needs a linked provider before it can authenticate anyone.

Configuring an OAuth2 or OIDC Application

Adding your first application to Authentik starts with creating a provider. Navigate to Applications – Providers and click Create. For most modern self-hosted apps, choose OAuth2/OpenID Provider. Give it a name, then set the authorization flow – the default default-authorization-flow works for most setups. Under Protocol Settings, you’ll define the client ID and secret (Authentik can auto-generate both), and you’ll add the redirect URI that the application expects after a successful login. This URI needs to match exactly what the application sends, including any trailing slashes or query parameters.

With the provider saved, go to Applications – Applications and create a new entry. Set the name, a slug (used in the URL), and link it to the provider you just created. You can also set an icon, a description, and access policy bindings from here. The policy engine is where Authentik gets genuinely useful for multi-service setups: you can restrict specific applications to specific user groups, require MFA before granting access, or build time-based access windows using expression policies written in Python.

On the application side – Grafana, Gitea, Paperless-ngx, and most other self-hosted services with OAuth2 support – you’ll enter the client ID, client secret, and the Authentik endpoints. The OpenID discovery URL follows the format https://your-domain/application/o/your-app-slug/.well-known/openid-configuration. Most apps can pull all required endpoint URLs automatically from this discovery document, so you only need to paste the one URL plus the credentials. After saving on both sides, log out of the target app and test the login flow. If the redirect fails, check that the redirect URI in Authentik matches the one the app is sending – this mismatch causes most first-time integration failures.

For applications that don’t support OAuth2 or OIDC natively, Authentik offers a proxy provider that works through a forward-auth setup with compatible reverse proxies. In this mode, Authentik sits in front of the app entirely and handles the authentication gate before any request reaches the backend. The app itself never needs to know Authentik exists. This is particularly useful for static sites, legacy dashboards, or anything where modifying the application’s own config isn’t practical.

Users, Groups, and MFA Enrollment

User management in Authentik lives under Directory – Users. You can create users manually, import them via LDAP if you have an existing directory, or configure sources like LDAP, SAML, or social logins (Google, GitHub, Discord, and others are supported out of the box). Each user gets a profile page with their group memberships, active sessions, active tokens, and device enrollments all listed in one view. Deactivating a user or revoking all their sessions takes two clicks from that screen.

MFA enrollment can be enforced at the flow level. Edit the default-authorization-flow or create a custom flow that includes an authenticator validation stage. When a user hits that stage without an enrolled device, Authentik can redirect them through an enrollment sub-flow before completing the login. TOTP works with any standard authenticator app, WebAuthn supports hardware keys and passkeys, and the static token option is there as a backup for edge cases. One practical note: if you lock yourself out of the admin account because MFA is required and you lose the device, the ak create_recovery_key command generates a temporary bypass token valid for a short window.

Outposts – Authentik’s proxy and LDAP components – run as separate processes and connect back to the Authentik server via an internal API. If you’re using the forward-auth proxy mode across multiple applications, a single outpost can handle all of them simultaneously. The outpost configuration specifies which applications it serves and which server it authenticates against, making it straightforward to scale out without duplicating services. For anyone already managing a layered self-hosted environment, pairing Authentik with a structured reverse proxy setup is where the day-to-day operational overhead drops significantly.