mirror of
https://github.com/goauthentik/authentik
synced 2026-04-25 17:15:26 +02:00
website/docs: Clean up reverse proxy documentation (#21132)
* Clean up reverse proxy documentation * website/docs: clarify reverse proxy header requirements * website/docs: lowercase reverse proxy component names * website/docs: clarify trusted proxy network wording * website/docs: point to trusted proxy config location * website/docs: use softer wording for proxy behavior * website/docs: lowercase outpost troubleshooting text * website/docs: remove redundant reverse proxy links * Update reverse-proxy.md Signed-off-by: Dominic R <dominic@sdko.org> * Update website/docs/install-config/reverse-proxy.md Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com> Signed-off-by: Dominic R <dominic@sdko.org> --------- Signed-off-by: Dominic R <dominic@sdko.org> Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com>
This commit is contained in:
Dominic R
@@ -2,24 +2,65 @@
|
||||
title: Reverse proxy
|
||||
---
|
||||
|
||||
Use this page when authentik is exposed through a reverse proxy or load balancer.
|
||||
|
||||
:::info
|
||||
Since authentik uses WebSockets to communicate with Outposts, it does not support HTTP/1.0 reverse proxies. The HTTP/1.0 specification does not officially support WebSockets or protocol upgrades, though some clients may allow it.
|
||||
authentik uses WebSockets for communication with Outposts. Your reverse proxy must support HTTP/1.1 or newer. HTTP/1.0 reverse proxies are not supported.
|
||||
:::
|
||||
|
||||
If you want to access authentik behind a reverse proxy, there are a few headers that must be passed upstream:
|
||||
## Required proxy headers
|
||||
|
||||
- `X-Forwarded-Proto`: Tells authentik and Proxy Providers if they are being served over an HTTPS connection.
|
||||
- `X-Forwarded-For`: Without this, authentik will not know the IP addresses of clients.
|
||||
- `Host`: Required for various security checks, WebSocket handshake, and Outpost and Proxy Provider communication.
|
||||
- `Connection: Upgrade` and `Upgrade: WebSocket`: Required to upgrade protocols for requests to the WebSocket endpoints under HTTP/1.1.
|
||||
When authentik is behind a reverse proxy, configure the proxy to forward the original request HTTP headers to authentik unchanged. These headers tell authentik which host the client requested, whether the original connection used HTTP or HTTPS, what the client IP address was, and whether the request is attempting to upgrade to a WebSocket connection.
|
||||
|
||||
It is also recommended to use a [modern TLS configuration](https://ssl-config.mozilla.org/) and disable SSL/TLS protocols older than TLS 1.3.
|
||||
At a minimum, preserve these headers in your reverse proxy configuration:
|
||||
|
||||
If your reverse proxy isn't accessing authentik from a private IP address, [trusted proxy CIDRs configuration](./configuration/configuration.mdx#listen-settings) needs to be set on the authentik server to allow client IP address detection.
|
||||
- `Host`
|
||||
|
||||
The following nginx configuration can be used as a starting point for your own configuration.
|
||||
Preserves the original host requested by the client. Required for security checks, correct URL handling, WebSocket handshakes, and communication with outposts and proxy providers.
|
||||
|
||||
```
|
||||
- `X-Forwarded-Proto`
|
||||
|
||||
Tells authentik whether the original client connection used HTTP or HTTPS.
|
||||
|
||||
- `X-Forwarded-For`
|
||||
|
||||
Preserves the original client IP address so authentik can determine where the request came from.
|
||||
|
||||
- `Connection: Upgrade` and `Upgrade: WebSocket`
|
||||
|
||||
Required to upgrade WebSocket requests when using HTTP/1.1.
|
||||
|
||||
It is also recommended to use a [modern TLS configuration](https://ssl-config.mozilla.org/).
|
||||
|
||||
## Trusted proxy networks
|
||||
|
||||
authentik only trusts proxy headers such as `X-Forwarded-For` when the request comes from a trusted proxy network.
|
||||
|
||||
By default, authentik trusts these proxy networks, but you can change the list of trusted proxy networks with [`AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS`](./configuration/configuration.mdx#authentik_listen__trusted_proxy_cidrs):
|
||||
|
||||
- `127.0.0.0/8`
|
||||
- `10.0.0.0/8`
|
||||
- `172.16.0.0/12`
|
||||
- `192.168.0.0/16`
|
||||
- `::1/128`
|
||||
|
||||
If your reverse proxy or load balancer connects to authentik from a public IP address or from a network outside that list, add that address range to `AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS`.
|
||||
|
||||
Set this authentik environment variable in your deployment configuration, such as your Docker Compose `.env` file or Kubernetes `values.yaml`. For more information, see [Configuration](./configuration/configuration.mdx#set-your-environment-variables).
|
||||
|
||||
Without this setting, authentik might:
|
||||
|
||||
- log the reverse proxy IP instead of the client IP
|
||||
- mis-handle forwarded headers
|
||||
- make debugging login or CSRF issues more difficult
|
||||
|
||||
## Example: nginx
|
||||
|
||||
The following nginx configuration is a reasonable starting point. It proxies to authentik's HTTPS listener on port `9443`.
|
||||
|
||||
If you proxy to authentik's HTTP listener instead, change the upstream port to `9000` and change `proxy_pass https://authentik;` to `proxy_pass http://authentik;`.
|
||||
|
||||
```nginx
|
||||
# Upstream where your authentik server is hosted.
|
||||
upstream authentik {
|
||||
server <hostname of your authentik server>:9443;
|
||||
@@ -52,8 +93,8 @@ server {
|
||||
ssl_certificate_key /etc/letsencrypt/live/domain.tld/privkey.pem;
|
||||
add_header Strict-Transport-Security "max-age=63072000" always;
|
||||
|
||||
# Proxy site
|
||||
# Location can be set to a subpath if desired, see documentation linked below:
|
||||
# Proxy authentik
|
||||
# If authentik is served under a subpath, also review:
|
||||
# https://docs.goauthentik.io/docs/install-config/configuration/#authentik_web__path
|
||||
location / {
|
||||
proxy_pass https://authentik;
|
||||
@@ -66,3 +107,9 @@ server {
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- CSRF errors when saving objects are usually caused by incorrect `Host` or `Origin` handling. See [Troubleshooting CSRF Errors](../troubleshooting/csrf.md).
|
||||
- Incorrect client IP addresses usually mean the proxy IP is not covered by `AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS`.
|
||||
- Broken outpost or proxy provider communication often means the WebSocket upgrade headers are missing or the proxy is not using HTTP/1.1 or newer.
|
||||
|
||||
@@ -4,6 +4,8 @@ title: Troubleshooting CSRF Errors
|
||||
|
||||
With some proxy setups, you might run into CSRF errors when attempting to create/save objects in authentik. This is usually caused by either the _Origin_ or _Host_ header being incorrect.
|
||||
|
||||
If authentik is running behind a reverse proxy, review the [Reverse proxy](../install-config/reverse-proxy.md) guide as well.
|
||||
|
||||
Open the system info API endpoint of your authentik instance by going to *https://authentik.company/api/v3/admin/system/*. Take note of the value of _HTTP_HOST_, make sure it matches the domain you're accessing authentik at, and make sure it does _not_ include any port numbers.
|
||||
|
||||
When submitting a POST request by updating/creating an object, open the browser's developer tools and check the _Network_ tab. Open the POST request and look at the request headers. Make sure the value of _Origin_ matches your authentik domain, without any ports.
|
||||
|
||||
Reference in New Issue
Block a user