Authelia
💡 Quick Navigation
Authelia is the authentication and access-control layer for my Home Lab. It usually is not the application users think about directly. Instead, it sits behind Nginx Proxy Manager and adds centralized login, 2FA, and access policy in front of sensitive services.
NPM handles traffic entry and reverse proxying. Authelia decides whether a request should be allowed through. Together, they turn external service access into more than just HTTPS: they add a clearer identity and permission boundary.
Important
This is a public note, so it intentionally does not include real domains, internal IPs, usernames, emails, groups, password hashes, session secrets, JWT secrets, OIDC keys, SMTP accounts, or full access-control rules.
🎯 Why I Use It
Not every service should expose its own login page directly
Many self-hosted services have their own login page, but that does not mean all of them should be directly exposed to external networks. As the service count grows, login flows, 2FA support, password policies, and security update quality become inconsistent.
Authelia helps centralize the first layer of access:
- Sensitive services pass through centralized login first
- 2FA can be required when appropriate
- Different services can use different access policies
- Backend services do not each need to reinvent the same outer protection layer
It makes NPM more than traffic forwarding
A plain reverse proxy answers “where should this domain go?” With Authelia, the entry layer can also answer “should this user be allowed in?”
That matters for admin panels, internal dashboards, file systems, monitoring pages, and other sensitive services.
🧱 Role in the Home Lab
flowchart TD U[User / Browser] --> NPM[Nginx Proxy Manager] NPM --> AUTH[Authelia] AUTH --> USERS[(Local Users)] AUTH --> DB[(MariaDB Storage)] NPM --> APP[Protected Services] APP --> DATA[(Service Data)]
Authelia lives in the entry security layer. It does not replace the backend service’s own account permissions. It is more like a front-door guard: check identity and policy first, then let valid requests reach the backend.
Deployment summary
| Item | Current approach |
|---|---|
| Deployment | Docker Compose |
| Image | authelia/authelia:latest |
| Restart policy | unless-stopped |
| Config directory | bind-mounted to /config |
| Active config | /config/configuration.yml |
| Authentication backend | File-based local users |
| Password hashing | Argon2id |
| Storage backend | MariaDB / MySQL |
| Notifier | SMTP |
| 2FA | TOTP configured |
| OIDC | Identity-provider config exists |
Note
The current image uses
latest. This is convenient for quick updates, but less reproducible for restore and rollback. A safer long-term approach is to pin a version tag and pair upgrades with backup and rollback notes.
🔁 NPM Forward Auth Flow
In my setup, Authelia is mainly used through NPM’s forward-auth / auth_request pattern.
sequenceDiagram participant User as User participant NPM as NPM participant Auth as Authelia participant App as Backend Service User->>NPM: Request protected URL NPM->>Auth: Check authentication and policy Auth-->>NPM: Allow or deny NPM->>App: Proxy request if allowed App-->>User: Response through NPM
Several NPM proxy hosts currently use Authelia protection. Before a request reaches the backend, Authelia checks whether the user is logged in, whether 2FA is required, and whether the access policy allows the request.
Responsibility split
| Component | Responsibility |
|---|---|
| NPM | domain, TLS, proxy host, headers, WebSocket, upstream routing |
| Authelia | login, 2FA, session, access-control decision, OIDC |
| Backend service | its own users, in-app authorization, data security |
NPM also passes authenticated identity information to upstream services through headers. This public note only records the pattern, not the actual header snippets or protected domains.
👤 Authentication Backend and User Data
Authelia currently uses a file-based local user database. For a small family environment, this is direct enough and easier to operate than introducing LDAP too early.
The user database contains sensitive data. This public note does not list:
- username
- display name
- group membership
- password hash
- TOTP / recovery-related data
The only public principles I keep
- The user database must be backed up
- A password hash is still not public information
- 2FA enrollment and recovery codes need private storage procedures
- Before adding family members, confirm restore and account-recovery workflows
🛡️ Access Control Model
Authelia access-control is one of the most sensitive parts of the system, so this public note describes only the model, not exact rules.
The current setup includes:
- default policy is deny
- required bypass rules for the auth portal itself
- two-factor protection for selected services
- policies can vary by domain, user, group, and network conditions
Principles I follow
- Default deny: if an entry is not explicitly allowed, it should not pass.
- Use 2FA for sensitive services: especially admin panels, password vaults, and internal dashboards.
- Do not rely only on the outer layer: backend services should keep their own login and permissions.
- Change rules in small verified steps: a bad access-control change can lock me out or accidentally loosen exposure.
🔐 2FA, Session, and OIDC
TOTP
TOTP is configured. It is the second factor I use most often for services that should not be protected by password alone.
I do not publish:
- issuer / domain
- user 2FA status
- TOTP secret
- recovery code
Session / Cookie
Session and cookie settings involve root domains, auth portal URLs, cookie domains, and session secrets. These must stay out of public notes.
The public principle is: cookie boundaries between Authelia, NPM, and service domains need to be consistent. Otherwise, users can get redirected back to login after authenticating or lose sessions across subdomains.
OIDC
The current configuration includes OIDC identity-provider settings. This means Authelia can act not only as a forward-auth layer, but also as an identity provider for services that support OIDC.
OIDC client IDs, client secrets, private keys, redirect URIs, and actual client lists should not be public.
💾 MariaDB, Backup, and Restore
Authelia uses MariaDB / MySQL as its storage backend. That means backing up /config alone is not enough.
What needs protection
| Data | Notes |
|---|---|
/config settings | configuration.yml, user database, backup/reference config |
| MariaDB state | Persistent storage backend data used by Authelia |
| Secrets | storage encryption key, session/JWT/reset/OIDC-related secrets |
| NPM config | forward-auth snippets and proxy host settings affect whether protection still works |
Post-restore checks
- Authelia container starts
- MariaDB storage is reachable
- Login flow works
- TOTP works
- NPM forward-auth still protects the intended services
- OIDC clients can still authenticate
- Protected backend services still keep their own authorization rules
Warning
If the storage encryption key, OIDC key, or session/JWT-related secrets are lost, the database may still exist but login state, OIDC, or encrypted data may not restore correctly.
⚠️ Operations Principles and Security Boundaries
Authelia is not a magic shield
Authelia protects the entry layer. It does not replace backend service security. Backend services still need:
- strong passwords or their own 2FA
- regular updates
- unnecessary registration or public features disabled
- limited admin permissions
- backup and restore procedures
Avoid locking yourself out during updates
Before changing access-control, session, cookie, OIDC, or forward-auth settings, I keep a rollback-ready copy. These mistakes may not crash the container, but they can break the login flow.
Public notes should describe the model, not the full config
Authelia’s configuration.yml and user database are not suitable for public publishing. Even if passwords are redacted, they can still reveal domains, policies, headers, groups, emails, or other useful attack information.
Conclusion
Authelia moves my Home Lab entry layer from “reverse proxy plus HTTPS” to “centralized authentication and access control.” Its split with Nginx Proxy Manager is clear: NPM handles entry and routing, while Authelia handles identity and policy.
But Authelia is also highly sensitive infrastructure. When sharing it publicly, the useful part is not the full configuration. The useful part is the architecture model, backup scope, restore checklist, and security boundaries.
Further reading: Home Lab Overview, Nginx Proxy Manager, OpenMediaVault