This Authelia SSO setup guide walks you through implementing single sign-on authentication for your self-hosted services on Unraid. Instead of managing separate login credentials for each application-or worse, leaving services exposed without authentication, You’ll create a centralised authentication portal that protects everything behind one secure login. This also creates a Multi-Factor Authentication (MFA) setup with Authelia as depending on applications, you have to loging to Authelia with a username and password and then separately loging to your application using it’s native username and password. We will write a separate guide on adding MFA using Authelia itself, i.e. Authelia with username and password and a TOTP or PIN for 2FA/MFA setup.

Important: What “SSO” Means in This Context

Authelia provides network-level Single Sign-On, meaning one login grants access to multiple services. However, it’s crucial to understand what this does and doesn’t do:

• What you get: One Authelia login protects access to all your services. Once authenticated, you can browse to any protected application without re-entering your Authelia credentials.
• Security benefit: Even if someone obtains an application password (like Ghost or WordPress), they cannot access it without first passing through Authelia authentication.

True application-level SSO (where you never see individual app login screens) requires applications that support OAuth/OIDC integration with Authelia-most self-hosted apps don’t support this natively. Applications with their own login systems (Ghost, WordPress, Nextcloud, etc.) will still require their individual logins once you’re past the Authelia gateway.

What You’ll Achieve:

We’re configuring Authelia as an authentication middleware between NGINX Proxy Manager and your applications. I will use Speedtest-Tracker as an example application hosted within my Unraid server (self-hosted) with authentication. Once complete, anyone attempting to access this service will be redirected to authelia.example.com for login before gaining access.

Why This Matters:

Many self-hosted applications either lack built-in authentication or use basic username/password schemes vulnerable to brute-force attacks. By implementing this Authelia SSO setup, you add an extra layer of security without modifying your applications. I use NPM (NGINX Proxy Manager) as a application proxy between internet and my local self-hosted network. In this case, NPM redirects the intial request to Authelia for SSO authenticationbefore traffic ever reaches the backend service. This approach scales beautifully-once configured, adding authentication to additional services requires minimal effort.

Prerequisites Check

What You Have:

• Unraid server with Docker enabled, or your own TrueNAS, QNAP, Synology or self-hosted network. This will also work in Cloud if you spin up a Authelia service.
• NGINX Proxy Manager installed (my setup)
• Cloudflare managing example.com or your domain name. I haven’t tested with other DNS providers but I don’t see why it wouldn’t work.
• monitoring.example.com → http://10.0.0.121:8080 a subdomain created in cloudflare or the DNS provider for monitoring.example.com and NPM configured to point to internal IP and port.
• SSL certificates configured. Pretty straight forward task in NPM.

What You’ll Add:

• Authelia container
• DNS A record: authelia.example.com
• NGINX proxy host for Authelia
• Configuration files (uses SQLite for storage). You can use proper DB but for the sake of simplicity (and because this is self-hosted) I prefer SQLite.

DNS Configuration in Cloudflare

1. Log into Cloudflare DNS management
2. Add A record:
   • Name: authelia
   • IPv4: Your public IP
   • Proxy: Enabled (orange cloud)
   • TTL: Auto
3. Save and wait 2-5 minutes for propagation

You can also point it to CNAME if your router supports Dynamic DNS. This might be prefereable to some if you have a dynamic IP from your ISP.

Result: authelia.example.com points to your NGINX Proxy Manager.

NGINX Proxy Manager – Create Authelia Proxy Host

Before installing Authelia, create the proxy host so you can access the authentication portal via domain.

1. Open NGINX Proxy Manager → Hosts → Add Proxy Host
2. Details tab:
   • Domain: authelia.example.com
   • Scheme: http
   • Forward IP: 10.0.0.121
   • Port:9091
   • Enable: Cache Assets, Block Exploits, Websockets
3. SSL tab:
   • Request Let’s Encrypt certificate
   • Enable Force SSL and HTTP/2
4. Save

The proxy host is ready – Authelia container will serve content once installed and configured.

Authelia Container Setup on Unraid

Install Authelia container from Community Applications. This guide uses SQLite for storage (suitable for home labs). For more details, see the official Authelia documentation.

Install Authelia

1. Apps tab → Search “authelia”
2. Select “Authelia” container
3. Configure:
   • Repository: authelia/authelia:latest
   • Network: bridge
   • Port: 9091
   • Volume: /mnt/user/appdata/authelia → /config
   • Add Variable: TZ = Australia/Sydney
4. Apply

Container will show errors until configuration files are created – this is expected.

Authelia Configuration Files

SSH into Unraid or use terminal:

cd /mnt/user/appdata/authelia

Generate Password Hash

Use a temporary container to generate the password hash:

docker run --rm authelia/authelia:latest authelia crypto hash generate argon2 --password 'YourSecurePassword123'

Copy the entire hash output (starts with $argon2id$v=19$...).  Important: Copy only the hash, no extra characters.

Create users_database.yml

Create the file:

nano users_database.yml

Add this content (use spaces, not tabs):

users:
  admin:
    displayname: "Admin User"
    password: "$argon2id$v=19$m=65536,t=3,p=4$hPlfImTgwrrHAoSACyasda1asd1fX$03x5svot1nCA1mjasdasd1asghjjUSbW9+0ONQngA"
    email: [email protected]
    groups:
      - admins

Replace the example hash with your generated hash. Ensure the hash is wrapped in quotes with no extra brackets or characters. Save with Ctrl+X, Y, Enter.

This is what the configuration.yml looks like, I’ve of course blacked out the actual details but it’s te same as above config.

Create configuration.yml

Generate required secrets first:

# JWT Secret
openssl rand -base64 64

# Encryption Key
openssl rand -base64 64

Save both outputs.

Create configuration file:

nano configuration.yml

Add this content, replacing placeholders with your actual values:

theme: dark
jwt_secret: i2kJQdqn4GixIuvWaTRDIasdasdasdasd00D2VggghjjjerghhT87Qm7Zajkkklsdkkkkkkghh0w==
default_redirection_url: https://authelia.example.com

server:
  host: 0.0.0.0
  port: 9091

log:
  level: info

authentication_backend:
  file:
    path: /config/users_database.yml
    password:
      algorithm: argon2id

access_control:
  default_policy: deny
  rules:
    - domain: monitoring.example.com
      policy: one_factor
      subject:
        - "group:admins"
    - domain: ghost.example.com
      policy: one_factor
      subject:
        - "group:admins"
    - domain: admin.example.com
      policy: one_factor
      subject:
        - "group:admins"
    - domain: files.example.com
      policy: one_factor
      subject:
        - "group:admins"
    - domain: wordpress.example.com
      policy: one_factor
      subject:
        - "group:admins"
    - domain: dashboard.example.com
      policy: one_factor
      subject:
        - "group:admins"

session:
  name: authelia_session
  domain: example.com
  expiration: 1h
  inactivity: 15m
  remember_me_duration: 1M

storage:
  encryption_key: i2kJQdqn4GixIuvWaTRDIasdasdasdasd00D2VggghjjjerghhT87Qm7Zajkkklsdkkkkkkghh0w==
  local:
    path: /config/db.sqlite3

notifier:
  filesystem:
    filename: /config/notification.txt

Replace these placeholders:

• YOUR_JWT_SECRET_HERE – Generate with: openssl rand -base64 64
• YOUR_ENCRYPTION_KEY_HERE – Generate with: openssl rand -base64 64

Configuration explanation:

• default_policy: deny – Blocks all access by default
• policy: one_factor – Requires username/password (Authelia login) before accessing each service
• Multiple domains shown – each protected service needs its own rule
• Session stores in browser cookies (no Redis needed for basic setup)
• Data stores in local SQLite database
• All services under example.com share the same Authelia session

Important: Applications with their own authentication (Ghost, WordPress, etc.) will still require their individual logins after passing through Authelia. Authelia acts as a network gateway, not an application login replacement.

Save with Ctrl+X, Y, Enter.

Set Permissions

chmod 644 /mnt/user/appdata/authelia/*.yml
chown -R 99:100 /mnt/user/appdata/authelia

Start Authelia

Restart the Authelia container from Unraid Docker tab.

Check logs for errors:

docker logs authelia

Should see: Authelia is listening on... with no error messages.

Test Authelia Access

1. Open browser to https://authelia.example.com
2. Should see Authelia login page
3. Login with:
   • Username: admin
   • Password: Your chosen password (not the hash)
4. Should successfully authenticate

If you see session errors, verify:

• You’re using https://authelia.example.com (not IP address)
• session.domain is set to example.com in configuration.yml
• JWT secret and encryption key are properly set

Configure Authentication Forwarding in NGINX

Now configure NGINX Proxy Manager to check authentication before serving protected services.

Protecting Speedtest-Tracker

1. In NGINX Proxy Manager, locate monitoring.example.com proxy host
2. Edit → Advanced tab
3. Add this configuration:

location /authelia {
    internal;
    set $upstream_authelia http://10.0.0.121:9091/api/verify;
    proxy_pass $upstream_authelia;
    proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
    proxy_set_header X-Forwarded-Method $request_method;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $http_host;
    proxy_set_header X-Forwarded-Uri $request_uri;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header Content-Length "";
    proxy_set_header Connection "";
    proxy_pass_request_body off;
    proxy_http_version 1.1;
    proxy_cache_bypass $cookie_session;
    proxy_no_cache $cookie_session;
}

location / {
    auth_request /authelia;
    auth_request_set $target_url $scheme://$http_host$request_uri;
    auth_request_set $user $upstream_http_remote_user;
    auth_request_set $groups $upstream_http_remote_groups;
    
    proxy_set_header Remote-User $user;
    proxy_set_header Remote-Groups $groups;
    
    error_page 401 =302 https://authelia.example.com/?rd=$target_url;
    
    proxy_pass http://10.0.0.121:8080;
}

4. Save and deploy

Configuration breakdown:

• /authelia location checks authentication status
• auth_request directive validates before serving content
• error_page 401 redirects unauthenticated users to login
• $target_url preserves destination for post-login redirect

Speedtest-Tracker now requires authentication through Authelia.

Testing the Authelia SSO Setup

Open incognito browser window to test complete flow.

Test authentication:

1. Navigate to https://monitoring.example.com
2. Should redirect to https://authelia.example.com
3. Enter credentials:
   • Username: admin
   • Password: Your password
4. Click “Sign in”
5. Automatic redirect back to Speedtest-Tracker that is hosted on monitoring.example.com
6. Application loads without additional prompts

Verify session persistence:

1. Close browser tab
2. Reopen https://monitoring.example.com
3. Loads directly (session active for 1 hour)
4. No authentication prompt

Check logs:

docker logs authelia

Look for: Authentication successful for user 'admin'

Test logout:

1. Visit https://authelia.example.com
2. Click logout icon
3. Try accessing Speedtest-Tracker which is setup on monitoring.example.com subdomain.
4. Should prompt for authentication again

Your Authelia SSO setup now protects Speedtest-Tracker with centralised authentication.

Expected Behaviour for Different Application Types:

• Apps without built-in auth (like Speedtest-Tracker): Will load directly after Authelia login
• Apps with their own auth (Ghost, WordPress, Nextcloud, ProjectSend): Will show their login screen after Authelia authentication. You’ll need to log into the application separately, but attackers cannot reach these login screens without passing through Authelia first.

Expanding Protection

To protect additional services, repeat the NGINX configuration pattern.

Steps:

1. Add service to access_control in configuration.yml:

- domain: goaccessnpm.example.com
  policy: one_factor
  subject:
    - "group:admins"

2. Restart Authelia container
3. Edit the service’s proxy host in NGINX Proxy Manager
4. Add the same authentication configuration to Advanced tab
5. Save and deploy

Each protected service redirects to authelia.example.com for authentication. Once authenticated, access all protected services without additional logins during your session.

For enhanced security with two-factor authentication, see the Step by Step Guide on Authelia MFA Setup on Unraid Server.

Related Guides

Enhance Your Authelia Setup:

• Step by Step Guide on Authelia MFA Setup on Unraid Server – Add two-factor authentication for enhanced security
• NGINX Proxy Manager Complete Setup Guide – Master reverse proxy configuration
• Top selfhosted Docker Containers on Unraid – Container security best practices
• Cloudflare DNS Configuration – Official Cloudflare DNS documentation
• Authelia Official Documentation – Comprehensive Authelia guides

Conclusion

Your Authelia SSO setup provides network-level authentication for your self-hosted services on Unraid. You’ve created a security gateway that requires authentication before users can reach your applications. Once authenticated with Authelia, you can access all protected services without re-entering your Authelia credentials during your session.

This setup provides authentication gatekeeper functionality, not application-level single sign-on. Applications with their own user systems (Nextcloud, GoAccessNPM, etc.) will still display their login screens after passing through Authelia. However, you’ve added a critical security layer-even if application credentials are compromised, attackers cannot access services without your Authelia login. This two-layer approach (Authelia + application login) significantly strengthens your security posture.

For production environments or sensitive data, implement multi-factor authentication by following the companion MFA setup guide. This adds time-based one-time passwords (TOTP) as a second authentication factor, further protecting against credential theft and unauthorised access.

That’s it, Enjoy!