Learn Authentik - Security Hardening

#Introduction

In episode 26, you made sure data can recover when disaster strikes. Now it's time to think about the more proactive question: how do you prevent the disaster from happening in the first place? An identity provider is the most valuable target in your infrastructure — if it's compromised, the attacker holds the keys to every connected application. One weak password on an admin account costs far more than all the hardening steps we're about to cover.

Think of security like the layers of an onion — no single layer saves you on its own, but a good combination of layers makes an attacker give up halfway. This episode is a map of those layers: from strengthened secrets, encrypted transport, to policies that make unimportant access hard to reach.

#Replace Default Secrets and Strengthen AUTHENTIK_SECRET_KEY

The first step that's most trivial yet most often forgotten: replace all default values. The initial account, example database credentials, and the AUTHENTIK_SECRET_KEY from the installation template are doors already fitted with factory keys — and everyone knows those keys. Default or weak keys let an attacker sign forged sessions, and in some cases even become a vector to read the metrics endpoint.

AUTHENTIK_SECRET_KEY must be random and long — at least 50 characters. Generate it with a cryptographic random source:

openssl rand -hex 64

Store the result in a safe place (episode 26), never commit it to Git, and don't share it. If you've ever exposed this key publicly, rotate it immediately — but remember that rotation re-signs all sessions, so plan the timing outside peak hours and inform users.

#TLS: Encryption at Every Point

There's no excuse for Authentik running without HTTPS. TLS termination happens at the reverse proxy or ingress (episodes 12, 13, 24), with certificates renewed automatically. Once HTTPS is active, force browsers to only use encrypted connections via the HSTS header:

server {
    listen 443 ssl http2;
    server_name auth.example.com;
 
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
 
    location / {
        proxy_pass http://authentik:9000;
    }
}

HSTS tells the browser "never try HTTP again" for the specified period — protecting users from downgrade attacks and forged certificates. Also make sure no HTTP listener exposes login data.

#Rate Limiting: Reducing the Attack Rate

Rate limiting restricts how many attempts an attacker can make within a time window — turning a brute force attack from a race of speed into a race of patience that never wins. This capability can be installed at the proxy (NGINX, Traefik, Caddy) and works together with Authentik's reputation system from episode 19.

limit_req_zone $binary_remote_addr zone=auth:10m rate=10r/m;
 
server {
    listen 443 ssl http2;
    server_name auth.example.com;
 
    location / {
        limit_req zone=auth burst=20 nodelay;
        proxy_pass http://authentik:9000;
    }
}

A limit that's too strict will disrupt legitimate users (for example many employees behind one NAT IP). Start with a moderate value, monitor with the alerting from episode 25, then adjust.

#Disable Unused Registration

If you don't offer public registration, disable the enrollment flow. The default enrollment flow lets anyone create an account — and new accounts are additional attack surface. Unbind the enrollment flow binding from the flow, or replace it with a deny stage inside it, and verify by trying to register from incognito mode: if you can, you're not done.

#A Clear Password Policy

The password policy is composed via the password policy on the authentication stage: minimum length, character mix, and reuse prohibition. A good policy balances security with usability — a policy forcing a change every 30 days often ends up with passwords repeated with an extra number at the end, which is actually weaker.

For enforcement, attach a policy that forces users to change a weak password before continuing, and combine it with a breached-password check if needed. Remember that a password is only one factor — the combination with 2FA matters far more.

#Enforcing 2FA, Especially for Admins

2FA changes the rules of the game: even a leaked password isn't enough to get in. TOTP and WebAuthn/FIDO2 (episode 7) are the recommended methods. Don't just offer 2FA — require it for admins. This can be done via an expression policy on the authentication stage:

Expression policy — require MFA for admins

if request.user.groups.filter(name="admins").exists():
    return request.user.ak_is_authenticator_setup_complete
return True

Note the logic: for members of the admins group, they must have completed authenticator setup; for others, let them pass (a comprehensive MFA policy can be added separately). Complement this with recovery code planning for admins who lose their device.

#Least Privilege: Don't Give Superuser to Everyone

A superuser account is a master key — and like a master key, the fewer people who hold it, the safer. Don't grant superuser to everyone who "manages" Authentik. Leverage the group and permission system: give the narrowest role for the job required. Set up a separate break-glass account not used daily, and monitor the audit events (episode 22) to detect unusual usage.

#Security Headers: Instructions to the Browser

HTTP headers are how the server tells the browser about policies. The ones that matter for Authentik: CSP (Content Security Policy) restricting which script and style sources may load, X-Frame-Options to prevent clickjacking (an Authentik page wrapped in an attacker's site iframe), and Referrer-Policy to limit URL leakage. Apply them at the proxy, but test first — an overly strict CSP can break the login page that loads Authentik's web assets.

#A Disciplined Update Cadence

Authentik releases updates regularly, and most security fixes arrive via new versions. Set a rhythm: upgrade staging first, then production, and read the release notes for breaking changes. Don't pile up several versions of delay — each jump adds the risk of difficult-to-resolve differences. Monitor CVE announcements and subscribe to the official release notes so you know when the version you're running contains a vulnerability that needs patching.

#Periodic Security Reviews

Hardening isn't a one-time project — it's a maintained process. Schedule routine reviews with a fixed question list: are the secrets in use still the strongest, does the superuser account still belong only to the right people, is there a registration flow accidentally open, and is the update cadence still running. The technical verification is quick: check the installed security headers with curl -I https://auth.example.com and compare them against your expectations.

Raise this to a regular exercise: once a year, perform a thorough audit combining audit events (episode 22), a review of each account's permissions, and a test of the key rotation procedure. A system hardened five years ago and never touched again isn't a secure system — it's just a system that hasn't been attacked yet.

#Closing

In this episode 27, you learned to strengthen Authentik from the inside out: replacing default secrets and strengthening AUTHENTIK_SECRET_KEY, enforcing TLS with HSTS at the proxy, installing rate limiting, disabling unused registration, building a password policy, requiring 2FA especially for admins, applying least privilege for superuser accounts, configuring security headers, and running a disciplined update cadence.

Key takeaways:

• Default keys and a weak AUTHENTIK_SECRET_KEY are doors whose keys everyone already knows.
• HTTPS without HSTS still leaves a downgrade gap.
• Required 2FA is worth more than complicated passwords.
• Least privilege: superuser only for those who truly need it.
• Updates are a living safeguard; a version backlog is security debt.

Even a well-locked door can still leave residents locked outside. In episode 28, we cover Troubleshooting & Debugging: reading server and worker logs, handling 500 errors, outposts failing to connect, OIDC redirect errors, SAML mismatches, database connection issues, session problems, plus using the flow inspector and community support channels. See you in episode 28!