Reverse Proxy: add Caddy + Authentik SSO Documentation

[luckylinux]

Is there an existing issue for this?

• I have searched the existing open and closed issues

Is your feature request related to a problem? Please describe

Implement Documentation based on my own Setup that I worked on in the past few Days 😃.

Describe the solution you'd like

• Describe Reverse Proxy Setup using Caddy for providing TLS Termination.
• Describe Authentik SSO Outpost Proxy Integration for automatic Sign-On using Authentik Identity Provider

Describe alternatives you've considered

N/A

Anything else?

I started adding Caddy + Podman + Authentik SSO Information in the REVERSE_PROXY Documentation Page.

https://github.com/luckylinux/NetAlertX/blob/add-caddy-and-authentik-sso-documentation/docs/REVERSE_PROXY.md

There are some Formatting Issues unfortunately though 😕.

Am I willing to test this? 🧪

• I will do my best to test this feature on the netlertx-dev image when requested within 48h and report bugs to help deliver a great user experience for everyone and not to break existing installations.

Can I help implement this? 👩‍💻👨‍💻

• Yes
• No

[luckylinux]

@jokob-sk: please let me know how the Documentation looks in my Branch and what should be improved before doing a PR.

Unfortunately I also saw that my Commits from the past few Days leaked my email address too, but I guess there's nothing that can be done at this Point, right 😕 ?

[jokob-sk]

Looks good (anything is better than nothing and we can improve in the future) - if you want you can copy your changes, delete the fork, fork again and that should destroy the commit history. Then you copy back your changes.

[luckylinux]

I mean the PR that got merged already (you can see it using e.g. git log on your Main Branch).

This Documentation Branch is fine.

[jokob-sk]

oh, sorry to hear that - that's difficult to get out of the commit history and I rather not mess with git on that level as it can break contributions, attribution and the repo integrity.

[luckylinux]

Well it's more I didn't want my domain to stand out in Public. Oh well, I'll just do the PR then.

[luckylinux]

@jokob-sk: Just to be sure, should the GraphQL Endpoint also be authenticated ? Or is it only the Web GUI ?

Right now I only implemented the Web GUI.

But I thought it would be better to double check this with you before doing the PR.

[luckylinux]

Even without GraphQL Endpoint being explicitely protected by Authentik SSO, I tried to access ONE GraphQL Endpoint directly via CURL:

USER@ubuntu:~/Repositories/github.com/netalertx$ curl -L -vvv https://netalertx-fedora.MYDOMAIN.TLD:20212/device/Internet?period=1%20month
* Host netalertx-fedora.MYDOMAIN.TLD:20212 was resolved.
* IPv6: (none)
* IPv4: 192.168.1.41
*   Trying 192.168.1.41:20212...
* Connected to netalertx-fedora.MYDOMAIN.TLD (192.168.1.41) port 20212
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / X25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=MYDOMAIN.TLD
*  start date: Nov XX XX:XX:XX 2025 GMT
*  expire date: Feb XX XX:XX:XX 2026 GMT
*  subjectAltName: host "netalertx-fedora.MYDOMAIN.TLD" matched cert's "*.MYDOMAIN.TLD"
*  issuer: C=US; O=Let's Encrypt; CN=E7
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://netalertx-fedora.MYDOMAIN.TLD:20212/device/Internet?period=1%20month
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: netalertx-fedora.MYDOMAIN.TLD:20212]
* [HTTP/2] [1] [:path: /device/Internet?period=1%20month]
* [HTTP/2] [1] [user-agent: curl/8.5.0]
* [HTTP/2] [1] [accept: */*]
> GET /device/Internet?period=1%20month HTTP/2
> Host: netalertx-fedora.MYDOMAIN.TLD:20212
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/2 403 
< alt-svc: h3=":20212"; ma=2592000
< content-type: application/json
< date: Sun, 11 Jan 2026 07:08:22 GMT
< server: Werkzeug/3.1.5 Python/3.12.12
< via: 1.1 Caddy
< content-length: 85
< 
{
  "error": "Forbidden",
  "message": "ERROR: Not authorized",
  "success": false
}
* Connection #0 to host netalertx-fedora.MYDOMAIN.TLD left intact

In NetAlertX Logs I see:

[api] Unauthorized access attempt - make sure your GRAPHQL_PORT and API_TOKEN settings are correct.

[jokob-sk]

Hi,

All requests need to be authenticated. See the docs for details https://jokob-sk.github.io/NetAlertX/API/?h=api

[luckylinux]

Uhm, I guess I'll need to let that go through Caddy + Authentik as well then 🤔.

But then the Question is how the server-to-server communication is going to work or is that simply via 0.0.0.0 ?

Because otherwise it's going to be the Web GUI having a problem of authenticating with the API, not so much the User.

[jokob-sk]

Sorry, not sure if I follow?

[luckylinux]

Well if you say that all requests must be authenticated, then the same thing I do for the Web GUI:

Client -> HTTPS Port 443 -> Caddy -> Forward Authentication to Authentik Outpost -> NetAlertX NGINX

I would have to do for the GraphQL Endpoint:

Client -> HTTPS Port 20212 -> Caddy -> Forward Authentication to Authentik Outpost -> NetAlertX GraphQL

[jokob-sk]

Yes, I think so.

[luckylinux]

Does that mean that effectively you ignore SETPWD_enable_password=false with regards to GraphQL ?

Because for the Web GUI SETPWD_enable_password=false works fine once Authentik SSO is in Place.

It seems that it's possible, using a Headless Client such as CURL, to authenticate against a Remote Host sitting behind Authentik. This Issue provides some Clue about OIDC Authentication via CURL:

goauthentik/authentik#3926

However one Developer/Contributor recommends in goauthentik/authentik#3926 (comment) to instead use:

• https://docs.goauthentik.io/add-secure-apps/providers/oauth2/client_credentials/
• https://docs.goauthentik.io/add-secure-apps/providers/oauth2/device_code/
• https://github.com/goauthentik/authentik/blob/main/internal/outpost/flow/executor.go

The Question then of course is how to implement it on your End, because I don't know how you could even read the X-Authentik-* Headers from your End.

All I see in the Debugger Console is some Set-Cookie with authentik_proxy_xxxxxxxxxxxxx when visiting NetAlertX and authentik_session= when hitting https://authentik.MYDOMAIN.TLD/application/o/authorize/ via the Authentik Outpost Proxy and
authentik_proxy_ on the Callback (when I am redirected back to NetAlertX), I don't see any of these Values in the other Pages unfortunately 😕.

Most probably there will need to be a Way to disable API_TOKEN on your End for the GraphQL API Server, if Authentik handles that Part too, possibly with the Exception of 0.0.0.0 (internal) - although not sure if you use the Token for internal-only Communication (between WebUI and GraphQL as in server-side, NOT via an additional Client HTTP Request I mean).