Caddy and Authentik
You link caddy and authentik by setting up forward auth between the two services. Caddy stops each web request and asks Authentik to check the user login first. Teams use this pair to put one login screen in front of internal web apps. Still, once a user logs in, broad role rules often grant full app rights. One stolen cookie or wide group role can expose every tool behind that web server. How caddy and authentik work together Caddy acts as the front door for all incoming web traffic on your
Authentik: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You link caddy and authentik by setting up forward auth between the two services. Caddy stops each web request and asks Authentik to check the user login first. Teams use this pair to put one login screen in front of internal web apps. Still, once a user logs in, broad role rules often grant full app rights. One stolen cookie or wide group role can expose every tool behind that web server.
How caddy and authentik work together
Caddy acts as the front door for all incoming web traffic on your network. When a user visits a protected web address, Caddy pauses that request right away. It sends a fast background check to the Authentik outpost to verify the session. Authentik reads the session cookie to see if the user has logged in yet.
If the user has no valid session, Authentik sends them to a login page. There, the user enters a password and completes a second factor check. Authentik also checks if the user belongs to the right group for this app. Once the login passes, Authentik tells Caddy that the user is good to go.
Authentik can also send back user details like an email address or group name. Caddy copies those details into web headers and sends the request to the app. The backend app reads those headers to know who is using the system today. This setup removes the need to build a separate login system for every app.
Why teams pair these two tools
Teams choose this pair because both tools are simple to run and maintain. Caddy manages web certificates on its own without manual work from the ops team. Authentik supports modern login rules and ties into central user directories with very little fuss. Together, they protect internal dashboards and legacy web tools that lack good login screens.
Admins can manage all user groups in one central place instead of ten apps. When an engineer leaves the team, disabling one account blocks their web logins everywhere. You also get a single log of when users sign in through the web.
Authentik: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What login checks miss during active sessions
This setup works well for basic web traffic, but it stops at the door. Caddy and Authentik only decide if a user may open a web app. They do not inspect what happens inside the app after the login step finishes. Once a user passes the gate, they can run any action their role allows.
Also, this pair only handles web traffic and ignores direct database or shell sessions. Engineers still need raw keys or passwords to query data or run server commands. Web login checks cannot stop a bad database query or a risky shell command. They also cannot rewrite sensitive fields like emails, phone numbers, or card numbers in results. While masking rewrites matched fields in results, a web server simply passes raw pages through. Teams still face big risks when an approved user runs a destructive query by mistake.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Does Caddy store user passwords when paired with Authentik?
No, Caddy never holds or checks user passwords on its own during this flow. Authentik stores the user records and handles the entire login check from start to finish. Caddy just asks Authentik if the current web request has a valid session cookie.
Can this setup protect database or command line tools?
Caddy and Authentik are built to manage browser traffic and standard web apps first. They do not inspect raw database queries or command line sessions at the command level. You need deeper controls to govern individual queries, shell commands, and sensitive data results.
How do backend apps know which user logged in?
After a good login, Authentik sends the user identity back to the Caddy server. Caddy places that user name, email, or group list into standard web request headers. Your backend app reads those trusted headers to set the right user view inside.