Imagine that all you had to do was register onceto get access to all your services - from the wiki to the cloud. And that completely self-hosted. Welcome to Authenticitythe modern open source tool for Single Sign-On (SSO) and Identity Management!
For detailed instructions and an explanation of all configuration options, I recommend the YouTube video linked below. In this video, every single setting is explained in detail so that you receive comprehensive instructions for the exact setup. You can find any code from the video in this article so that you can use it directly without having to type it in.
This blog post and video is part of a series in which we create and set up our own home server. We start with the basics like an Ubuntu VM installation with Docker and then continue with the configuration of your own domain, security precautions and above all lots of cool and useful self-hosted services. Whether media servers like Plex or Jellyfin or document management like Paperless-NGX. Together we'll build the setup you want to see. We even tackle topics such as single sign-on (SSO) together.
What is Single Sign-On (SSO) and Identity Management?
Before we enter the world of Authenticity immersion, it is important to understand what Single Sign-On (SSO) and Identity Management are at all.
Single Sign-On (SSO)
SSO allows you to unique and then access multiple connected services without having to authenticate yourself again. Whether Nextcloud, Gitea or Grafana: one login - everything open.
Advantages of SSO:
- User-friendly: fewer logins, less frustration.
- Security: Fewer passwords means less attack surface.
- Management: Centralized control over access.
Identity Management
Identity management is all about Management of user identitiestheir authorizations and access to systems. Modern systems allow you to manage:
- External identity providers (e.g. Google, Azure AD)
- User accounts
- Roles & Groups
- Authentication methods (password, 2FA, certificates)
What is authenticity?
Authenticity is a modern, open-source identity management and authentication system that specializes in self-hosting. It combines centralized authentication services with sophisticated access policies, user management and protocol compatibility. Authentik speaks protocols such as OAuth2, OpenID Connect, SAML 2.0 and LDAP - which makes it the ideal SSO and IAM solution for almost any infrastructure.
It was developed in Python, uses Django as a framework and offers a modern, user-friendly web interface for admins and users. Authentik is aimed at both beginners in self-hosting and professional administrators with complex requirements.
Terms explained
- TOTP (Time-based One-Time Password): A one-time code that is generated on a time basis (e.g. Google Authenticator).
- WebAuthn: Modern, passwordless authentication using hardware tokens (e.g. YubiKey) or biometric devices.
- Reverse Proxy Outposts: Prefabricated integrations that act as a reverse proxy and pre-switch authentication - for example for services that do not support native authentication protocols.
- External IdPs (identity providers): Systems such as Google, Microsoft or GitHub, through which users can alternatively log in to Authentik - helpful for federated identities or hybrid setups.
Central functions at a glance
- OpenID Connect & OAuth2 Provider: For modern web apps and APIs
- SAML 2.0: Compatibility with enterprise services
- LDAP Proxy: Legacy support for older services
- MFA support: TOTP, WebAuthn, FIDO2, backup codes
- Reverse Proxy Outposts: Integration without code integration
- Granular access policies: Time-dependent, IP-based, role-based
- Integrate external IdPs: Google, Azure, GitHub, SAML etc.
- User flow system: Customizable registration, login and approval processes
- Audit Logging & Analytics: Transparency for admins
- API & webhook support: Automation and DevOps friendliness



Structure and architecture of Authentik
Authentik allows you to control the entire login process in detail - and visually via a clear web interface.
Components of authenticity:
- Core: The central service that orchestrates logic, user management, authentication and policies.
- Flows: User interactions such as login, registration, password reset or approval processes. Each flow is modularly customizable.
- Applications: Abstractions for the services to be protected. This is where you define how and via which protocol a service should authenticate itself.
- Providers: Technical interfaces for OAuth2, OpenID Connect, SAML or LDAP - they connect authentication with the applications.
- Policies: Rule systems that allow you to define who gets access - depending on time, IP address, user attributes or group membership.
- Outposts: Authentik's own reverse proxy components based on Nginx or Traefik, which can be placed directly in front of services and handle authentication via Authentik.
How does authenticity work in practice?
- You register via Authentik.
- Authentics checks identity, MFA, guidelines.
- After successful authentication, you will be redirected to your service.
- Authentik forwards a token or SAML assertion to the app.
Security features in detail
Multi-factor authentication (MFA)
Authentik offers MFA with:
- TOTP (Time-based One-Time Password): A time-based code, e.g. via Google Authenticator.
- WebAuthn/FIDO2: Hardware authentication via YubiKey, fingerprint sensor or biometric methods.
- Backup codes: One-time codes for emergency registration.
Policy Engine
Policies are at the heart of Authentik's security model. You can:
- Fine granular Define access rights.
- Make access dependent on time, IP, geo-location or user role.
- Dynamically decide whether a flow is continued or canceled.
Protocol compatibility
Authentik supports secure standards such as:
- OAuth2 & OpenID Connect: For modern web applications and APIs.
- SAML 2.0: For legacy applications and enterprise software.
- LDAP Proxy: For the integration of older services.
Auditing and transparency
Every action, every login, every policy decision is logged. You receive:
- Traceable logs
- Insight into failed login attempts
- Diagnostic aids for integration problems
Secure storage
- Passwords are stored using secure algorithms such as PBKDF2 + SHA256.
- Secrets and tokens are stored in encrypted form in the backend.
Integrations & compatibility
The best thing about authenticity: you can almost every application that supports one of the common authentication protocols - and these days that is almost all web-based tools.
Thanks to the support of OAuth2, OpenID Connect, SAML 2.0 and LDAP Authentik is compatible with:
- classic web services such as Nextcloud, GitLab, Gitea, Grafana, Mattermost
- Enterprise software such as Jira, Confluence, Rocket.Chat, Zammad
- Dashboard and admin tools such as Portainer, Kubernetes dashboards
- internal in-house developments, APIs or admin interfaces
Whether modern API authentication via OAuth2 or legacy login via SAML or LDAP - Authentik adapts.
An admin can therefore build an end-to-end single sign-on solution where users only enter their password once and are then authorized across all systems - without password chaos or double logins.
You can even integrate external identity providers such as Google or Azure AD - perfect if you want to combine hybrid identity management with self-hosting.
Practical examples of authenticity in action
Example 1: Homelab with multiple services
Do you run a Homelab with Nextcloud, Gitea, Grafana and Portainer? Instead of managing a separate password everywhere, set up Authentik as a central identity provider. All services are connected to Authentik via OAuth2 or SAML. Result: One login - all services available. And for all other users too. Of course, this is especially true for services that you make freely available on the Internet.
Example 2: Small agency with internal wiki and customer access
In your agency, internal employees use a wiki (e.g. Wiki.js or Outline) and customers access a support portal. With Authentik, you set up two different user groups. Your policies only allow customers access to the support portal, while employees have full access - controlled via roles and groups.
Example 3: Legacy software via LDAP
An old ERP system only supports LDAP for authentication. Instead of maintaining your own LDAP server, use Authentik's LDAP proxy. This keeps all identities centrally managed and synchronized.
Example 4: External login via Google
Do you want to make it easy for users to log in with existing Google accounts? In Authentik, you configure Google as an external IdP. Users log in with their Google account, but are assigned roles and rights that are controlled centrally via Authentik. You are probably familiar with this variant from many providers where you can log in with Google, Microsoft, Apple or something else. It is the same principle and is simply very convenient and easy for users.
Comparison: Authentik vs. Keycloak vs. Authelia vs. Entra ID
Feature | Authenticity | Keycloak | Authelia | Entra ID (Azure AD) |
---|---|---|---|---|
Self-hosted | Yes | Yes | Yes | No |
Open Source | Yes | Yes | Yes | No |
OAuth2 / OpenID Connect | Yes | Yes | No | Yes |
SAML | Yes | Yes | Restricted | Yes |
LDAP support | Yes (proxy) | Yes | No | Restricted |
MFA (TOTP, WebAuthn, etc.) | Yes | Yes | Yes | Yes |
User management UI | Modern & intuitive | Functional | Minimalist | Very modern |
Roles & Groups (RBAC) | Yes | Yes | Restricted | Yes |
Flow-based processes | Yes | Partially | No | Yes |
Policy Engine | Strong & flexible | Strong | Medium | Strong |
DevOps/API integration | Very good (webhooks, API) | Good | Restricted | Yes |
Scalability | High | High | Medium | Very high |
Complexity | Medium | High | Low | High |
Hosting options | Docker, K8s, bare metal | Docker, K8s, bare metal | Docker | Cloud only |
Conclusion: Authenticity is a good compromise between Functionality, Usability and Self-hosting friendliness.
Advantages of Authentik at a glance
- ✅ Open Source & free of charge
- ✅ Simple self-hosting with Docker
- ✅ GDPR-compliant, as no cloud required
- ✅ Modern UI & rapid further development
- ✅ Flexibly expandable
- ✅ Integration with almost all modern web services
Who is Authentik suitable for?
- Homelab enthusiasts
- Self-hosting with multiple web applications
- Small to medium-sized companies that take data protection seriously
- Developers who want to build secure login systems
Installation of Authentik via Docker
To do this, you simply create a YAML file on your server with the following content (of course you make adjustments for sensitive data such as passwords or mail services):
services:
authentik:
image: beryju/authentik:2025.6.4
container_name: authentik
command: server
restart: unless-stopped
networks:
- sascha
ports:
- 9002:9000
- 9444:9443
environment:
TZ: Europe/Berlin
AUTHENTIK_REDIS__HOST: redis
AUTHENTIK_POSTGRESQL__HOST: authentik-db
AUTHENTIK_POSTGRESQL__USER: authentik
AUTHENTIK_POSTGRESQL__NAME: authentik
AUTHENTIK_POSTGRESQL__PASSWORD: superSafePassword
AUTHENTIK_ERROR_REPORTING__ENABLED: true
AUTHENTIK_SECRET_KEY: superSecretKey
AUTHENTIK_REDIS__PASSWORD:
AUTHENTIK_REDIS__DB: 1
AUTHENTIK_EMAIL__HOST: mail.host.net
AUTHENTIC_EMAIL__PORT: 587
AUTHENTIK_EMAIL__USERNAME: [email protected]
AUTHENTIK_EMAIL__PASSWORD: mailPassword
AUTHENTIK_EMAIL__USE_TLS: true
AUTHENTIK_EMAIL__USE_SSL: false
AUTHENTIK_EMAIL__TIMEOUT: 10
AUTHENTIK_EMAIL__FROM: [email protected]
volumes:
- /mnt/cache/appdata/security/authentik/templates:/templates:rw
- /mnt/cache/appdata/security/authentik/media:/media:rw
authentik-worker:
image: beryju/authentik:2025.6.4
container_name: authentik-worker
command: worker
user: root # needed for Docker Socket to work
restart: unless-stopped
networks:
- sascha
environment:
TZ: Europe/Berlin
AUTHENTIK_REDIS__HOST: redis
AUTHENTIK_POSTGRESQL__HOST: authentik-db
AUTHENTIK_POSTGRESQL__USER: authentik
AUTHENTIK_POSTGRESQL__NAME: authentik
AUTHENTIK_POSTGRESQL__PASSWORD: superSafePassword
AUTHENTIK_SECRET_KEY: superSecretKey
AUTHENTIK_REDIS__PASSWORD:
AUTHENTIK_REDIS__DB: 1
volumes:
- /mnt/cache/appdata/security/authentik/backups:/backups:rw
- /mnt/cache/appdata/security/authentik/media:/media:rw
- /mnt/cache/appdata/security/authentik/certs:/certs:rw
- /mnt/cache/appdata/security/authentik/templates:/templates:rw
authentik-db:
image: postgres:latest
container_name: authentik-db
restart: unless-stopped
networks:
- sascha
ports:
- 5436:5432
environment:
TZ: Europe/Berlin
POSTGRES_PASSWORD: superSafePassword
POSTGRES_USER: authentik
POSTGRES_DB: authentik
volumes:
- /mnt/cache/appdata/security/authentik-db:/var/lib/postgresql/data:rw
healthcheck:
test: ["CMD-SHELL", "pg_isready -U authentik -d authentik"]
interval: 10s
timeout: 5s
retries: 3
networks:
sascha:
external: true
You can then simply start the services with the following command (the name must of course be adapted):
docker compose -f "docker-compose-authentik.yml" up -d
Explanation of the Docker Compose
In a typical setup with Docker Compose, Authentik consists of several services:
The container authenticity
is the main server. It uses the official Docker image beryju/authentics
in a specific version and is activated with the command server
is started. The container is part of a named network and listens on ports 9000 (HTTP) and 9443 (HTTPS), which are mapped locally to 9002 and 9444 respectively. To ensure that the service restarts after a crash restart: unless-stopped
activated.
The environment variables configure the time zone, the connection to the PostgreSQL database (AUTHENTIC_POSTGRESQL__HOST
, USER
, PASSWORD
), the Redis instance for caching and security settings such as a secret key (AUTHENTIC_SECRET_KEY
). In addition, mail server settings are stored that enable Authentik to send emails for password resets or notifications.
The volumes integrate local directories into the system - including for templates and uploaded media.
The second container authentic-worker
executes background tasks, such as processing e-mails, webhooks or tasks from flows. The same image version is also used here, but with the start command worker
. The container requires access to the same database and Redis instance as the main server. It also mounts additional volumes, e.g. for backups and certificates.
The container authentic-db
provides the PostgreSQL database. It is based on the official postgres
-image, stores data in the local volume, uses a health check command (pg_isready
) for monitoring and can be reached externally via port 5436. This also ensures that the container restarts automatically in the event of an error.
All three services are located in the network sasha
which is declared as external - possibly a user-defined, existing network for a larger infrastructure. This can of course be changed at will and is only mentioned here for my example.
Bonus: Integration in NGINX Proxy Manager

YouTube video implementation
Conclusion: Your identity center in the palm of your hand
With Authenticity you get a powerful, modern and self-hosted solution for centralized authentication and user management. Whether you just want to secure Nextcloud or control an entire corporate network - Authentik offers you all the tools you need to do this securely, efficiently and transparently.
If you've had enough of insecure passwords, inconsistent user management and dependence on cloud services, now is the perfect time to switch to authentication.
0 Comments