Status: CURRENT — ENVIRONMENT-SPECIFIC FIX
Last reviewed: 31 August 2026
Applies to: Portainer + Authentik OAuth/OIDC behind Traefik with UFW enabledThis was the fix for my setup. If disabling UFW immediately makes the Authentik login work, the firewall path is involved. Docker and UFW interact in slightly weird ways though, so don’t assume every Docker host will behave exactly the same.
I use Authentik with Traefik for SSO, and Portainer authenticates against Authentik using OAuth/OIDC.
Authentik still has a Portainer integration guide, although that page still notes it was originally based on Authentik 2021.7.3 and Portainer 2.6.x. Portainer’s current documentation still supports a Custom OAuth provider.
This post isn’t another full Portainer/Authenik setup guide. It’s for the stupid problem I hit after the OAuth configuration looked correct.
The problem
When I tried logging into Portainer through Authentik, the login failed. Inspecting the browser console showed a request returning 404, which eventually resulted in a 401 Unauthorized.
Portainer, Authentik and Traefik were already on the expected Docker networks and changing the Traefik configuration wasn’t getting me anywhere.
The thing that finally exposed the problem was testing with UFW disabled.
Check UFW first
Before changing anything, check the current firewall state:
sudo ufw status verboseIf Traefik is supposed to be reachable over HTTPS but there is no rule allowing the traffic you expect, that is worth investigating before ripping apart your Authentik configuration.
Temporarily disable UFW as a test
Diagnostic test only: disabling the firewall removes protection from the host while it is off. Don’t leave UFW disabled as the fix.
Temporarily disable UFW:
sudo ufw disableNow try the Portainer → Authentik login again.
In my case it immediately worked. That told me the OAuth configuration itself wasn’t the problem — traffic involved in the HTTPS authentication flow was being blocked by my firewall setup.
Why being on the same Docker network didn’t save it
This caught me out because Portainer, Authentik and Traefik were on Docker networks together.
OAuth/OIDC isn’t necessarily just container-to-container traffic. Your browser is redirected between the Portainer and Authentik HTTPS URLs, and the callback returns through those hostnames. If the HTTPS path to Traefik is broken, the authentication flow can fail even though the containers themselves can communicate internally.
Docker + UFW warning: Docker’s normal published ports are implemented with Docker-managed firewall/NAT rules, and Docker documents that published container ports can bypass the normal UFW INPUT/OUTPUT rules.
Because of that,
ufw allow 443is not universally required for every Docker-published Traefik instance. If toggling UFW changes the result on your host, inspect how Traefik exposes 80/443 and any custom forwarding/firewall rules rather than assuming this exact fix applies everywhere.
Check how Traefik is listening
A quick check on the Docker host:
sudo ss -lntp | grep -E ':(80|443)\b'You can also check Docker’s published ports:
docker ps --format 'table {{.Names}}\t{{.Ports}}'This helps work out whether Traefik is listening directly on the host, using Docker port publishing, host networking, or something more customised.
The fix on my host
Once I confirmed UFW was involved, I re-enabled it and allowed HTTP/HTTPS for Traefik.
If you’re connected to the server remotely over SSH, make sure SSH is already allowed before enabling UFW or you can lock yourself out.
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp comment 'Allow HTTP for Traefik'
sudo ufw allow 443/tcp comment 'Allow HTTPS for Traefik'
sudo ufw enable
sudo ufw reloadThen confirm the rules:
sudo ufw status numberedAfter that, the Portainer login through Authentik worked normally again.
Do you actually need port 80?
Not necessarily. If your Traefik setup only needs HTTPS and you aren’t using port 80 for an HTTP → HTTPS redirect or an ACME HTTP challenge, then you may only need:
sudo ufw allow 443/tcp comment 'Allow HTTPS for Traefik'Open only what your setup actually needs.
If disabling UFW does NOT fix it
Then stop blaming UFW 😅 and go back through the OAuth flow.
- Confirm the Portainer redirect URL exactly matches the redirect URI configured in Authentik.
- Confirm Portainer’s Authorization, Access Token and Resource/UserInfo URLs point at the correct Authentik instance.
- Check the Client ID and Client Secret.
- Portainer’s OAuth scopes should be space-separated, not comma-separated.
- Confirm both the Portainer and Authentik hostnames are reachable from the browser performing the login.
- Check Traefik and Authentik logs while reproducing the login.
Portainer’s current documentation still supports Settings → Authentication → OAuth → Custom, so the general Authentik-as-OIDC-provider design remains valid.
Summary
For me, the giveaway was simple:
UFW enabled → Authentik login fails
UFW disabled → Authentik login worksThat narrowed the problem from “something is broken in Authentik/Portainer/Traefik” to “the firewall path is involved”, which was a hell of a lot easier to troubleshoot.
Just remember that Docker’s own firewall rules can bypass UFW for normally published container ports, so treat this as a troubleshooting method and my specific fix rather than a universal Docker rule.
