Open-source authentication and authorization server providing multi-factor authentication (MFA), single sign-on (SSO), and OpenID Connect 1.0 Provider. Supports LDAP, file-based identity providers, TOTP, WebAuthn, Duo Push, passkeys, fine-grained access control rules, session management via Redis, and proxy integration with NGINX, Traefik, Caddy, Envoy, HAProxy. Use when deploying or configuring Authelia for authentication gateways, SSO portals, MFA enforcement, or OpenID Connect identity provider setups.
Instrucciones de origen · Vista previa de solo lectura
name
authelia-4-39-19
description
Open-source authentication and authorization server providing multi-factor authentication (MFA), single sign-on (SSO), and OpenID Connect 1.0 Provider. Supports LDAP, file-based identity providers, TOTP, WebAuthn, Duo Push, passkeys, fine-grained access control rules, session management via Redis, and proxy integration with NGINX, Traefik, Caddy, Envoy, HAProxy. Use when deploying or configuring Authelia for authentication gateways, SSO portals, MFA enforcement, or OpenID Connect identity provider setups.
Authelia 4.39.19
Overview
Authelia is an open-source authentication and authorization server that provides multi-factor authentication (MFA) and single sign-on (SSO) for applications behind a reverse proxy. Written in Go with a React frontend, it operates as a companion to reverse proxies — intercepting authentication requests via the proxy while never touching application payloads directly.
Authelia serves two primary integration modes:
Proxy Authorization (Forwarded Authentication): The proxy forwards each request to Authelia's /api/verify or /api/authz/* endpoints. Authelia checks session cookies and returns 200 (allow), 401/302 (redirect to login portal), or 403 (deny) based on access control policies.
OpenID Connect 1.0 Provider: Authelia acts as an OpenID Certified™ identity provider, enabling applications that implement the OIDC Relying Party role to authenticate users through Authelia.
Key characteristics: compressed container under 20 MB, memory usage typically under 30 MB, HTTPS-only operation (HTTP not supported), session cookies for SSO across subdomains.
When to Use
Deploying Authelia as an authentication gateway behind a reverse proxy
Configuring multi-factor authentication (TOTP, WebAuthn, Duo Push, passkeys) for web applications
Setting up single sign-on (SSO) across multiple domains via session cookies or OpenID Connect
Writing access control rules to enforce per-domain, per-path, or per-user authentication levels
Integrating Authelia with Docker, Kubernetes, or bare-metal deployments
Configuring proxy integrations for NGINX, Traefik, Caddy, Envoy, HAProxy, or Skipper
Setting up OpenID Connect 1.0 as an identity provider for third-party applications
Core Concepts
Architecture
Authelia sits between the reverse proxy and application backends. The proxy sends authentication requests to Authelia; Authelia never sees application payloads. Requests are identified by forwarded headers (X-Forwarded-Proto, X-Forwarded-Host, X-Forwarded-For, X-Forwarded-URI).
Authentication Flow (Proxy Authorization)
Unauthenticated request hits the proxy → proxy forwards to Authelia's authz endpoint
Authelia checks for a valid session cookie → none found, returns 302 redirect to login portal
User authenticates at the Authelia portal (1FA + optional 2FA) → session cookie issued
Subsequent requests include the session cookie → proxy forwards it to Authelia → Authelia returns 200 → request passes through
Authorization Model
Authelia evaluates rules sequentially against each request. A rule matches when all its criteria match: domain/domain_regex, resources (path regex), subject (user/group), networks (CIDR or named groups), and methods (HTTP verbs). The matched rule's policy determines the required authentication level:
deny — access denied regardless of authentication state
bypass — no authentication required
one_factor — 1FA sufficient
two_factor — both 1FA and 2FA required
Rules are evaluated in order; first match wins. An unauthenticated user cannot match rules with subject criteria.
Session Cookies
Session cookies enable SSO across configured domains. Each cookie entry specifies a domain, authelia_url, session duration (inactivity, expiration, remember_me), and same_site behavior. For high-availability deployments (Kubernetes), use Redis as the session provider instead of the default in-memory store.
First Factor / Second Factor
First Factor (something you know): Username + password via LDAP or YAML file backend
Second Factor (something you have): TOTP, WebAuthn (security keys/passkeys), or Duo Push notifications
Password Policy: Enforce minimum strength requirements with configurable criteria
