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?

  1. You register via Authentik.
  2. Authentics checks identity, MFA, guidelines.
  3. After successful authentication, you will be redirected to your service.
  4. 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

FeatureAuthenticityKeycloakAutheliaEntra ID (Azure AD)
Self-hostedYesYesYesNo
Open SourceYesYesYesNo
OAuth2 / OpenID ConnectYesYesNoYes
SAMLYesYesRestrictedYes
LDAP supportYes (proxy)YesNoRestricted
MFA (TOTP, WebAuthn, etc.)YesYesYesYes
User management UIModern & intuitiveFunctionalMinimalistVery modern
Roles & Groups (RBAC)YesYesRestrictedYes
Flow-based processesYesPartiallyNoYes
Policy EngineStrong & flexibleStrongMediumStrong
DevOps/API integrationVery good (webhooks, API)GoodRestrictedYes
ScalabilityHighHighMediumVery high
ComplexityMediumHighLowHigh
Hosting optionsDocker, K8s, bare metalDocker, K8s, bare metalDockerCloud 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 sashawhich 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.

Useful links

The product display was implemented using the affiliate-toolkit WordPress plugin.

0 Comments

Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

en_US