Authelia is an open-source authentication and authorization server. Authelia brings 2-factor authentication and single sign-on to secure web applications and ease authentication. It has been designed to be a companion of any reverse proxy by helping it handle authentication and authorization requests.
Authelia can be installed on bare-metal using Docker or npm but can also be deployed easily on a Kubernetes cluster and leverages ingress controller and ingress configuration concepts to easily configure authentication and authorization for specific services in your cluster by simply editing your ingress configuration.
- Features summary
- Deployment
- Getting started
- Features in details
- Security
- Documentation
- Contributing to Authelia
- License
- Two-factor authentication using either TOTP - Time-Base One Time password - or U2F - Universal 2-Factor - as 2nd factor.
- Password reset with identity verification using email.
- Single and two factors authentication methods available.
- Access restriction after too many authentication attempts.
- User-defined access control per subdomain and resource.
- Support of basic authentication for endpoints protected by single factor.
- High-availability using a highly-available distributed database and KV store.
- Compatible with Kubernetes ingress-nginx controller out of the box.
If you don't have any LDAP and/or nginx setup yet, I advise you to follow the Getting Started section. That way, you can test it right away without even configuring anything.
Otherwise, here are the available steps to deploy Authelia on your machine given your configuration file is /path/to/your/config.yml. Note that you can create your own the configuration file from config.template.yml at the root of the repo.
npm install -g authelia
authelia /path/to/your/config.yml
docker pull clems4ever/authelia
docker run -v /path/to/your/config.yml:/etc/authelia/config.yml -v /path/to/data/dir:/var/lib/authelia clems4ever/authelia
where /path/to/data/dir is the directory where all user data will be stored.
Please refer to the following README.
The provided example is docker-based so that you can deploy and test it very quickly.
Make sure you have npm and node installed on your computer.
Make sure you have docker and docker-compose installed on your machine. For your information, here are the versions that have been used for testing:
docker --version
gave Docker version 17.03.1-ce, build c6d412e.
docker-compose --version
gave docker-compose version 1.14.0, build c7bdf9e.
Make sure you don't have anything listening on port 8080 (webserver) and 8085 (webmail).
Add the following lines to your /etc/hosts to alias multiple subdomains so that nginx can redirect request to the correct virtual host.
127.0.0.1 home.example.com
127.0.0.1 public.example.com
127.0.0.1 dev.example.com
127.0.0.1 admin.example.com
127.0.0.1 mx1.mail.example.com
127.0.0.1 mx2.mail.example.com
127.0.0.1 single_factor.example.com
127.0.0.1 login.example.com
Deploy the Authelia example with one of the following commands:
Build Docker container from current commit:
./scripts/build-dev.sh
./scripts/example-commit/deploy-example.sh
Use provided container on DockerHub:
./scripts/example-dockerhub/deploy-example.sh
After few seconds the services should be running and you should be able to visit https://home.example.com:8080/.
When accessing the login page, a self-signed certificate exception should appear, it has to be trusted before you can get to the target page. The certificate must also be trusted for each subdomain, therefore it is normal to see the exception several times.
Below is what the login page looks like:
Authelia uses an LDAP server as the backend for storing credentials. When authentication is needed, the user is redirected to the login page which corresponds to the first factor. Authelia tries to bind the username and password against the configured LDAP backend.
You can find an example of the configuration of the LDAP backend in config.template.yml.
In Authelia, you can register a per user TOTP (Time-Based One Time Password) secret before authenticating. To do that, you need to click on the register button. It will send a link to the user email address stored in LDAP. Since this is an example, the email is sent to a fake email address you can access from the webmail at http://localhost:8085. Click on Continue and you'll get your secret in QRCode and Base32 formats. You can use Google Authenticator to store them and get the generated tokens with the app.
Note: If you're testing with npm, you will not have access to the fake webmail. You can use the filesystem notifier (option available config.template.yml) that will create a file containing the validation URL instead of sending an email. Please only use it for testing.
Authelia also offers authentication using U2F (Universal 2-Factor) devices like Yubikey USB security keys. U2F is one of the most secure authentication protocol and is already available for Google, Facebook, Github accounts and more.
Like TOTP, U2F requires you register your security key before authenticating. To do so, click on the register button. This will send a link to the user email address. Since this is an example, the email is sent to a fake email address you can access from the webmail at http://localhost:8085. Click on Continue and you'll be asking to touch the token of your device to register. Upon successful registration, you can authenticate using your U2F device by simply touching the token. Easy, right?!
Note: If you're testing with npm, you will not have access to the fake webmail. You can use the filesystem notifier (option available config.template.yml) that will create a file containing the validation URL instead of sending an email. Please only use it for testing.
With Authelia, you can also reset your password in no time. Click on the Forgot password? link in the login page, provide the username of the user requiring a password reset and Authelia will send an email with an link to the user email address. For the sake of the example, the email is delivered in a fake webmail deployed for you and accessible at http://localhost:8085. Paste the link in your browser and you should be able to reset the password.
Note: If you're testing with npm, you will not have access to the fake webmail. You can use the filesystem notifier (option available config.template.yml) that will create a file containing the validation URL instead of sending an email. Please only use it for testing.
With Authelia, you can define your own access control rules for finely restricting user access to some resources and subdomains. Those rules are defined and fully documented in the configuration file. They can apply to users, groups or everyone. Check out config.template.yml to see how they are defined.
Authelia allows you to customize the authentication method to use for each sub-domain.The supported methods are either "single_factor" or "two_factor". Please see config.template.yml to see an example of configuration.
It is also possible to use basic authentication to access a resource protected by a single factor.
When your users authenticate against Authelia, sessions are stored in a Redis key/value store. You can specify your own Redis instance in config.template.yml.
Authelia uses two mechanism to protect against cookie theft:
- session attribute
httpOnlyset to true make client-side code unable to read the cookie. - session attribute
secureensure the cookie will never be sent over an unsecure HTTP connections.
Since Authelia uses multi-domain cookies to perform single sign-on, an attacker who poisonned a user's DNS cache can easily retrieve the user's cookies by making the user send a request to one of the attacker's IPs.
To mitigate this risk, it's advisable to only use HTTPS connections with valid certificates and enforce it with HTTP Strict Transport Security (HSTS) so that the attacker must also require the certificate to retrieve the cookies.
Note that using HSTS has consequences. That's why you should read the blog post nginx has written on HSTS.
You can also apply the following headers to your nginx configuration for improving security. Please read the documentation of those headers before applying them blindly.
# We don't want any credentials / TOTP secret key / QR code to be cached by
# the client
add_header Cache-Control "no-store";
add_header Pragma "no-cache";
# Clickjacking / XSS protection
# We don't want Authelia's login page to be rendered within a <frame>,
# <iframe> or <object> from an external website.
add_header X-Frame-Options "SAMEORIGIN";
# Block pages from loading when they detect reflected XSS attacks.
add_header X-XSS-Protection "1; mode=block";
The configuration of the server is defined in the file config.template.yml. All the details are documented there. You can specify another configuration file by giving it as first argument of Authelia.
authelia config.custom.yml
A wiki is available if you need more details about Authelia.
There is a complete API documentation generated with apiDoc and embedded in the repo under the doc/ directory. Simply open index.html locally to watch it.
Follow contributing file.
Authelia is licensed under the MIT License. The terms of the license are as follows:
The MIT License (MIT)
Copyright (c) 2016 - Clement Michaud
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.