Important: When using these guides, it’s important to recognize that we cannot provide a guide for every possible
method of deploying a proxy. These guides show a suggested setup only, and you need to understand the proxy
configuration and customize it to your needs. To-that-end, we include links to the official proxy documentation
throughout this documentation and in the See Also section.
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.
You need the following to run Authelia with NGINX:
NGINX must be built with the http_auth_request module which is relatively common
NGINX must be built with the http_realip module which is relatively common
NGINX must be built with the http_set_misc module or the nginx-mod-http-set-misc package if you want to use the
legacy method and preserve more than one query parameter when redirected to the portal due to a limitation in NGINX
Important: You should read the Forwarded Headers section and this section as part of any proxy configuration.
Especially if you have never read it before.
Important: The included example is NOT meant for production use. It’s used expressly as an example to showcase
how you can configure multiple IP ranges. You should customize this example to fit your specific architecture and needs.
You should only include the specific IP address ranges of the trusted proxies within your architecture and should not
trust entire subnets unless that subnet only has trusted proxies and no other services.
NGINX’s http_realip module is used to configure the trusted proxies’ configuration. In our examples this is
configured in the proxy.conf file. Each set_realip_from directive adds a trusted proxy address range to the trusted
proxies list. Any request that comes from a source IP not in one of the configured ranges results in the header being
replaced with the source IP of the client.
This guide makes a few assumptions. These assumptions may require adaptation in more advanced and complex scenarios. We
can not reasonably have examples for every advanced configuration option that exists. Some of these values can
automatically be replaced with documentation variables.
Documentation Variable Configuration
The following are the assumptions we make:
Deployment Scenario:
Single Host
Authelia is deployed as a Container with the container name authelia on port 9091
Proxy is deployed as a Container on a network shared with Authelia
The above assumption means that Authelia should be accessible to the proxy on http://authelia:9091 and as such:
You will have to adapt all instances of the above URL to be https:// if Authelia configuration has a TLS key and
certificate defined
You will have to adapt all instances of authelia in the URL if:
you’re using a different container name
you deployed the proxy to a different location
You will have to adapt all instances of 9091 in the URL if:
you have adjusted the default port in the configuration
You will have to adapt the entire URL if:
Authelia is on a different host to the proxy
All services are part of the example.com domain:
This domain and the subdomains will have to be adapted in all examples to match your specific domains unless you’re
just testing or you want to use that specific domain
NGINX utilizes the AuthRequest Authz implementation. The
associated Metadata should be considered required.
The examples below assume you are using the default
Authz Endpoints Configuration or one similar to the
following minimal configuration:
The examples below also assume you are using the modern
Session Configuration which includes the domain, authelia_url, and
default_redirection_url as a subkey of the session.cookies key as a list item. Below is an example of the modern
configuration as well as the legacy configuration for context.
The following docker compose example has various applications suitable for setting up an example environment.
It uses the nginx image from linuxserver.io which includes all of the
required modules including the http_set_misc module.
It also includes the nginx-proxy-confs mod where
they have several configuration examples in the /config/nginx/proxy-confs directory. This can be omitted if desired.
If you’re looking for a more complete solution linuxserver.io also have an nginx container called SWAG
which includes ACME and various other useful utilities.
Authelia is accessible to NGINX process with the hostname authelia on port 9091 making the URL
http://authelia:9091. If this is not the case adjust all instances of this as appropriate.
The NGINX configuration is in the folder /config/nginx. If this is not the case adjust all instances of this as
appropriate.
The URL you wish Authelia to be accessible on is https://auth.example.com. If this is not the case adjust all
instances of this as appropriate.
This example is for using the Authelia portal redirection flow on a specific endpoint. It requires you to have the
authelia-location.conf,
authelia-authrequest.conf, and proxy.conf snippets. In the example these
files exist in the /config/nginx/snippets/ directory. The /config/nginx/snippets/ssl.conf snippet is expected to have
the configuration for TLS or SSL but is not included as part of the examples.
The directive include /config/nginx/snippets/authelia-authrequest.conf; within the location block is what directs
NGINX to perform authorization with Authelia. Every location block you wish for Authelia to perform authorization for
should include this directive.
This example is for using HTTP basic auth on a specific endpoint. It is based on the full example above. It requires you
to have the authelia-location-basic.conf,
authelia-authrequest-basic.conf, and proxy.conf snippets. In the
example these files exist in the /config/nginx/snippets/ directory. The /config/nginx/snippets/ssl.conf snippet is expected to have
the configuration for TLS or SSL but is not included as part of the examples.
The Authelia Portal file from the Standard Example configuration can be reused for this example as
such it isn’t repeated.
The following configuration files are snippets that are used as includes in other files. The includes in the other files
match the headings, so if you wish to put them in a specific location or rename them, then make sure to update the
includes appropriately. Only the proxy.conf, authelia-location.conf, and
authelia-authrequest.conf are required; see the descriptions for the others as to their
use cases.
The following is an example proxy.conf. The important directives include the real_ip directives which you should read
Trusted Proxies section to understand, or set the X-Forwarded-Proto, X-Forwarded-Host,
X-Forwarded-URI, and X-Forwarded-For headers.
The following snippet is used within the server block of a virtual host as a supporting endpoint used by
auth_request and is paired with authelia-authrequest.conf.
The following snippet is used within a location block of a virtual host which uses the appropriate location block
and is paired with authelia-location.conf.
The following snippet is used within the server block of a virtual host as a supporting endpoint used by
auth_request and is paired with authelia-authrequest-basic.conf. This particular
snippet is rarely required. It’s only used if you want to only allow
HTTP Basic Authentication for a particular
endpoint. It’s recommended to use authelia-location.conf instead.
Note
This example assumes you configured an authz endpoint with the name auth-request/basic and the
implementation AuthRequest which contains the HeaderAuthorization and HeaderProxyAuthorization strategies.
The following snippet is used within a location block of a virtual host which uses the appropriate location block
and is paired with authelia-location-basic.conf. This particular snippet is rarely
required. It’s only used if you want to only allow
HTTP Basic Authentication for a particular
endpoint. It’s recommended to use authelia-authrequest.conf instead.
The following snippet is used within the server block of a virtual host as a supporting endpoint used by
auth_request and is paired with authelia-authrequest-detect.conf. This particular
snippet is rarely required. It’s only used if you want to conditionally require
HTTP Basic Authentication for a particular
endpoint. It’s recommended to use authelia-location.conf instead.
The following snippet is used within a location block of a virtual host which uses the appropriate location block
and is paired with authelia-location-detect.conf. This particular snippet is rarely
required. It’s only used if you want to conditionally require
HTTP Basic Authentication for a particular
endpoint. It’s recommended to use authelia-authrequest.conf instead.