authentik
goauthentik · Identity & access
GitHub stars
26,165Awaiting first sync
No measured star history yet
What is authentik?
authentik gives a company one place to manage who can sign in to which application. Instead of each tool keeping its own passwords, apps send people to authentik, which checks who they are and hands back the result. You run it on your own servers, from a small home lab to a large Kubernetes cluster, and decide exactly how each login works.
authentik is an open-source identity provider for single sign-on, built to be self-hosted. Applications connect to it over OAuth 2.0 and OpenID Connect, SAML, LDAP, RADIUS or SCIM, and a proxy provider protects apps that have no login of their own. Sign-in steps are built from flows and stages, so teams can add passkeys, one-time codes or enrolment forms without writing code.
Core capabilities
- Single sign-on over OAuth 2.0, OpenID Connect, SAML, LDAP, RADIUS and SCIM.
- A proxy provider adds a login in front of apps that have none.
- Flows and stages for passkeys, TOTP, Duo, SMS and email codes, and enrolment.
Providers for modern and older apps
Each application in authentik is paired with a provider, which sets how that app signs people in. Providers cover OAuth 2.0 and OpenID Connect, SAML, LDAP, RADIUS and SCIM, and a remote access provider gives browser-based RDP and SSH access to machines. The proxy provider protects apps with no login support, either by proxying traffic itself or by answering forward auth checks from an existing reverse proxy. Outposts run the proxy, LDAP, RADIUS and remote access parts and can be deployed anywhere they can reach the authentik API.
- OIDC
- SAML
- LDAP
- RADIUS
- Proxy
Flows, stages and sources
Login, enrolment and recovery are built as flows, and each flow is a sequence of stages such as identification, password and authenticator validation. Policies and bindings decide when a stage runs and for which users or groups. Authenticator stages cover WebAuthn security keys and passkeys, TOTP apps, Duo, SMS, email codes and static backup codes. Sources connect authentik to existing directories and logins, including LDAP, Active Directory, SAML, OAuth and social logins such as GitHub or Discord.
- Flows
- MFA
- Passkeys
- Sources
Run it with Docker Compose or Kubernetes
The documentation recommends Docker Compose for test and small production setups, on a host with at least 2 CPU cores and 2 GB of memory, and the Helm chart for larger installs on Kubernetes. Official AWS CloudFormation templates and a DigitalOcean Marketplace app are also available. After starting the containers, you open port 9000 in a browser and set a password for the default akadmin user. The core is licensed under MIT, while code in the authentik/enterprise folder is under a separate licence and powers paid Enterprise features such as Google Workspace and Entra ID sync and enhanced audit logging.
- MIT
- Docker Compose
- Kubernetes
- Helm
Where it fits
Use cases
- 01
Put internal apps behind one login
In the Admin interface, go to Applications and use New Application to create an application and its provider together, choosing OAuth2/OpenID Connect or SAML. For SAML you can upload the service provider's metadata file instead of typing the settings. Users then see every app they are allowed to use on their Application Dashboard.
- 02
Add a login to apps that have none
Create a proxy provider for the app and choose proxy mode, or forward auth if your existing reverse proxy should keep handling traffic. The authentik outpost checks each request, sends people to the login page when needed and passes headers such as X-authentik-username and X-authentik-groups to the app. The embedded outpost covers simple setups, and the Docker or Kubernetes integration can deploy extra outposts for you.
- 03
Require passkeys or one-time codes at sign-in
Under Flows and Stages, create a WebAuthn, TOTP or static backup code authenticator setup stage and bind it to a flow. The default authentication flow already includes an authenticator validation stage, and bindings let you run a stage only for certain users or groups. Add sources such as LDAP or a social login to the identification stage so people can sign in with accounts they already have.