An introduction into integrating Authelia with a reverse proxy.

Authelia works in collaboration with several reverse proxies. In this section you will find the documentation of the various tested proxies with examples of how you may configure them. We are eager for users to help us provide better examples of already documented proxies, as well as provide us examples of undocumented proxies.

Get Started

It’s strongly recommended that users setting up Authelia for the first time take a look at our Get Started guide. This takes you through various steps which are essential to bootstrapping Authelia.


See support for support information.

Required Headers

Authelia itself requires information about the actual request made to the portal. Each proxy is different and you should refer to each of the individual proxy documents, however the following headers are considered required when secured behind a reverse proxy:

UsagePrimary SourceFallback SourceExample Values
SchemeX-Forwarded-Proto (header)TLS (listening socket state)https, http
HostX-Forwarded-Host (header)Host (header),
PathX-Forwarded-URI (header)Request Target (Request Start Line)/, /api/state
Remote IPX-Forwarded-For (header)Source IP (TCP Packet),,

Important Note: these headers should match exactly with the URL displayed in the users browser for specifically the Authelia application when formatted like <scheme>://<host>>path>.

Integration Implementation

Authelia is capable of being integrated into many proxies due to the decisions regarding the implementation. We handle requests to the /api/verify endpoint with specific headers and return standardized responses based on the headers and the policy engines determination about what must be done.

Destination Identification

The method to identify the destination of a request relies on metadata headers which need to be set by your reverse proxy. The headers we rely on for this purposes are exactly the same as those required by Required Headers.

Important Note: these headers should match exactly with the URL displayed in the users browser for specifically the protected application when formatted like <scheme>://<host>>path>.

In addition the following headers have specific purposes specifically for protected application authorization:

Original Request MethodX-Forwarded-Method
Full Original URLX-Original-URLThis header must replace the related X-Forwarded-* headers and be exactly the full URL displayed in the users browser address bar

User Identification

A logged in user must be identified via standard means. Users are identified by one of two methods:

Response Statuses

Authelia responds in various ways depending on the result of the authorization policies.

When the user is authenticated and authorized to access a resource we respond with a HTTP 200 OK. When the user is not logged in and we need them to authenticate with 1FA, or if they are already authenticated with only 1FA and they need to perform 2FA, the user is redirected to the portal with:

When the user is denied either by a default policy, or by an explicit policy we respond with a HTTP 403 Forbidden status.

Response Headers

With the exception of the 403 Forbidden and 200 OK status responses above, Authelia responds with a Location header to redirect the user to the authentication portal.

In the instance of a 200 OK status response Authelia also responds with various headers which can be forwarded by your reverse proxy to the backend application which are potentially useful for SSO depending on if the backend application supports it.

See the Trusted Header SSO documentation for more information.