Primary question: Can your team operate a self-hosted IdP and restrict who can create or modify expression-based policies?
RepoDaily adoption score
RepoDaily rates this as 87/100 (strong) for adoption: evidence, installation path, production risk, differentiation, license clarity, and AI/agent fit are scored from the article sources and adoption notes.
5 source(s) across 3 source category/categories, plus a RepoDaily-specific evidence module when available.
5 workflow step(s), 4 next-action step(s), and 5 command/install signal(s) were detected.
Trending momentum is +123 stars, with maintenance/release/issue signals counted when present.
Risk is marked medium, with 5 security note(s) and 3 explicit skip condition(s).
3 opportunity lens item(s), 4 alternative(s), and 3 type-specific section(s) support differentiation.
License source or license wording is present.
2 AI/agent-related signal(s) were detected in the article text and metadata.
Project overview
authentik is an open-source Identity Provider (IdP) positioned for modern single sign-on. The repository README defines it as software that supports SAML, OAuth2/OIDC, LDAP, RADIUS, and additional protocols, and it is designed for self-hosting from small labs to large production clusters. The project presents itself as an alternative to commercial IdPs such as Okta, Auth0, Entra ID, and Ping Identity, with a separately licensed enterprise offering for organizations that need large-scale identity management.
The project supports four documented installation paths. Docker Compose is recommended for small or test setups, a Kubernetes Helm chart is recommended for larger deployments, AWS CloudFormation templates cover deployments on AWS, and a DigitalOcean Marketplace app provides one-click deployment. The Helm chart lives in a separate repository at goauthentik/helm, which keeps the core application code and the deployment manifests as distinct artifacts.
authentik is primarily written in Python and is built around a server component, outposts, and a web frontend. The CI badges in the README reference three workflows: ci-main.yml for the core build, ci-outpost.yml for the outpost build, and ci-web.yml for the web build. Code coverage is tracked through Codecov, and Docker images are published under authentik/server with semantic version tags.
Why it is trending now
- The project gained 123 period stars and ranked 19th on the trend list, reflecting sustained interest in self-hosted identity infrastructure.
- The README positions authentik as a replacement for Okta, Auth0, Entra ID, and Ping Identity, which aligns with organizations seeking vendor-independent identity layers.
- Supported versions listed in SECURITY.md include 2026.2.x and 2026.5.x, indicating an active release cadence under a year-based versioning scheme.
- The package.json version field reads 2026.11.0-rc1, suggesting the next named release is already in release-candidate preparation.
Problem it solves
- Organizations locked into commercial IdPs face licensing costs and limited control over policy logic and data residency.
- Teams that need SAML, OAuth2/OIDC, LDAP, and RADIUS in a single product often have to stitch multiple tools together.
- Self-hosted identity infrastructure is hard to deploy consistently across Docker Compose, Kubernetes, and cloud-native environments without curated templates.
How it works
- Deploy the server component using Docker Compose for a lab setup or the Helm chart for Kubernetes-based production clusters.
- Configure outposts, which are the components that proxy and bridge protocols such as LDAP and RADIUS to the core authentik server.
- Define providers for the protocols you need, such as SAML, OAuth2/OIDC, LDAP, or RADIUS, and attach them to applications.
- Use flows and policies to control authentication, enrollment, and recovery paths, including expression-based policies that can run Python code.
- Integrate applications through the protocol endpoints exposed by authentik, and monitor the build status of the core, outpost, and web components via CI badges.
Deployment Paths Documented in the README
The README lists four installation methods. Docker Compose is recommended for small and test setups, with documentation at docs.goauthentik.io under the install-config/install/docker-compose path. Kubernetes deployments use the Helm chart maintained in the goauthentik/helm repository and documented under install-config/install/kubernetes. AWS deployments use official CloudFormation templates documented under install-config/install/aws. DigitalOcean deployments use the marketplace app listed at marketplace.digitalocean.com/apps/authentik.
Protocols and Build Components
- Protocols: SAML, OAuth2/OIDC, LDAP, RADIUS, and additional protocols referenced in the README.
- Core build: tracked through the ci-main.yml GitHub Actions workflow.
- Outpost build: tracked through the ci-outpost.yml workflow, covering protocol proxy components.
- Web build: tracked through the ci-web.yml workflow, covering the front-end application.
- Container distribution: Docker images published under authentik/server with semver tags.
Versioning, Security Cadence, and Expression Risk
SECURITY.md lists 2026.2.x and 2026.5.x as currently supported versions, with the latest patch release for each version receiving support. The project states a commitment to regular pentesting and external audits, with details referenced in its Security documentation. CVE classification follows NVD CVSS scoring, with severity categories ranging from None at 0.0 through Critical at 9.0 to 10.0.
A notable maintenance risk is documented under Intended Functionality in SECURITY.md: expressions in property mappings, policies, and prompts can execute arbitrary Python code without safeguards. The project explicitly states that this is expected behavior and that any user with permission to create or modify objects containing expression fields can write code executed within authentik. This design choice places operational responsibility on administrators to restrict write access to expression-capable objects.
Who should pay attention?
Good fit if
- Teams replacing a commercial IdP who want self-hosted SAML, OIDC, LDAP, and RADIUS from one product.
- Platform engineers standardizing on Kubernetes who can consume the goauthentik/helm chart.
- Organizations that can restrict administrative access to expression-based policy fields.
Skip for now if
- Teams without capacity to operate and patch a self-hosted identity service.
- Environments where every identity feature must come with vendor SLAs and monetary bug bounties.
- Use cases requiring that end-users or low-trust admins can safely edit policy expressions without code-level risk.
Risks and cautions
The core product is MIT-licensed, documented, and deployed through multiple official paths, but the intentional ability for expression policies to run arbitrary Python code means administrative access must be tightly controlled.
- SECURITY.md documents that expressions in property mappings, policies, and prompts can execute arbitrary Python code without safeguards.
- No monetary bounties are offered for vulnerability reports, which may reduce external researcher incentive.
- The supported version matrix is limited to the two most recent named releases, requiring organizations to keep pace with upgrades.
- Self-hosted deployment introduces operational responsibility for uptime, patching, and backup of identity infrastructure.
- SECURITY.md states the project follows responsible disclosure and asks researchers to avoid public reporting.
- Vulnerability reports are accepted via security@goauthentik.io or through the GitHub private security advisory portal.
- The project commits to regular pentesting and external audits, with details referenced in its Security documentation.
- CVE eligibility is determined using NVD CVSS scoring, with severity bands from None through Critical.
- Expression-based policies are classified as intended functionality, not a vulnerability, because they rely on administrator trust.
Alternatives to compare
| Approach | When to use | Trade-off |
|---|---|---|
Keycloak | When you want a widely adopted open-source IdP with SAML and OIDC and a large community. | Free under Apache 2.0. |
Zitadel | When you want an open-source identity platform with a focus on multi-tenant cloud-native deployments. | Free under Apache 2.0 with a managed cloud option. |
Okta | When you need a fully managed commercial IdP with vendor SLAs. | Commercial subscription. |
Auth0 | When you want a developer-focused hosted identity service with broad integration libraries. | Commercial subscription with a free tier. |
What this trend reveals
Consolidate protocol coverage into one IdP
authentik supports SAML, OAuth2/OIDC, LDAP, and RADIUS in a single product, which removes the need to operate separate LDAP proxies and SAML bridges.
Confirm protocol coverage matches your application inventory by testing each provider type against a representative application.
Standardize deployment on the Helm chart
The goauthentik/helm chart provides a Kubernetes-native deployment path for production clusters, reducing the need for custom manifests.
Deploy the chart into a staging cluster and exercise outpost connections for LDAP and RADIUS before production rollout.
Reduce IdP vendor spend
The README positions authentik as a replacement for Okta, Auth0, Entra ID, and Ping Identity, which may reduce licensing costs for organizations that can self-host.
Compare total cost of ownership, including operations staff time, against current commercial IdP contracts.
RepoDaily verdict
authentik is a credible self-hosted identity provider for teams that need SAML, OAuth2/OIDC, LDAP, and RADIUS from one product, provided they can control administrative access to expression-based policies and keep pace with the supported version matrix.