CSRF failures since upgrade - Unusable

[Abrynos]

Describe the bug

Ever since I upgraded from my old version (the current release on the 22nd of July 2022 [going by directory creation date]) to the current 2022.11.3 release, I cannot log into any of my applications, nor am I able to change any settings in Authentik.

To Reproduce
Steps to reproduce the behavior:

1. Set up Authentik with the release from 2022-07-22 according to the official docs using Docker deployment
2. Follow through with all the config steps and set up Authentik behind an nginx reverse proxy
3. Upgrade your docker containers to the newest version
4. ...?

Expected behavior
Everything works the same as before

Screenshots

When trying to log into grafana (running on monitoring.mydomain.tld; authentik is at sso.mydomain.tld):

Full string since screenshot cuts it off:

No variant of ChallengeTypes exists with 'component=undefined'

When trying to edit anything in Authentik:

Logs
Output of docker-compose logs or kubectl logs respectively
authentik_worker.log
authentik_server.log

Version and Deployment (please complete the following information):

• authentik version: 2022.11.3
• Deployment: docker-compose

[lukasz-adamski]

I had the same problem on my Kubernetes based installation with nginx ingress controller. This was caused by the lack of X-Forwarded headers and setting use-forwarded-headers.

[Abrynos]

I do have the X-Forwarded-* headers set. My nginx config:

map $http_upgrade $connection_upgrade_keepalive {
        default upgrade;
        ''      '';
}

upstream authentik {
        server localhost:1234;
        keepalive 10;
}

server {
        server_name sso.mydomain.tld;
        listen 443 ssl http2;
        listen [::]:443 ssl http2;

        ssl_certificate /etc/letsencrypt/live/sso.mydomain.tld/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/sso.mydomain.tld/privkey.pem;
        ssl_protocols TLSv1.3;
        ssl_prefer_server_ciphers off;

        server_tokens off;
        more_set_headers 'Server: None Of Your Bussiness';

        location / {
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Host $host:$server_port;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header X-Forwarded-Server $host;
                proxy_set_header X-Real-IP $remote_addr;

                proxy_set_header Host $host;

                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection $connection_upgrade_keepalive;

                proxy_http_version 1.1;
                proxy_pass https://authentik/;
        }
}

[a3linux]

I have the similar configuration and got the same error message.
Could I know how to debug this if it is because of missed X-Forwarded-* headers?

[a3linux]

I tried docker tag 2022.12, seems it fixed.
But I use "ak dump_config" and I can NOT find the csrf_trusted_origins setting item even though I set it in /data/user_settings.py, that's wired.

[Abrynos]

I've just updated to the latest release and it still does not work for me.

[BeryJu]

You can navigate to /api/v3/admin/system/ (when authenticated) which will return all the headers authentik gets

When configuring custom settings via /data/user_settings.py, they will not show up with ak dump_config, as that only shows settings which are configured through the standard config system

[a3linux]

Thanks. @BeryJu That's helpful.
This is reasonable for /data/user_settings.py.
Could I know for other guys, the content of dump_config has csrf_trusted_origins, for me, there is no such item. Is it said I missed some configuration in my docker-compose?

[BeryJu]

dump_config has by default no csrf_trusted_origins entry as that is not a default configuration option, since it shouldn't have to be configured

[BeryJu]

https://goauthentik.io/docs/troubleshooting/csrf should fix this

[madewithpat]

Dusting this off to ask what the actual fix is. The docs page is helpful for identifying the error, but doesn’t provide any recommended fixes.

I’m using SWAG (nginx) with configs that look sound, but the HTTP_HOST that I get back from the api has port 443 in it. I wouldn’t think that should cause an issue.

[Abrynos]

Add user_settings.py with below content besides your docker compose file

CSRF_TRUSTED_ORIGINS = ["https://sso.my.domain.tld", "https://some.service.my.domain.tld", "https://*.my.domain.tld"]

Add a volume binding to your docker compose file

...
  server:
    image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:latest
    command: server
    volumes:
      - ./user_settings.py:/data/user_settings.py
...

[madewithpat]

@Abrynos is this a better path than fixing nginx files? I’m using SWAG’s auto proxy mod, but fine with writing the nginx conf files myself if that’s the more stable way to resolve this

[Abrynos]

is this a better path than fixing nginx files?

I have not found a way of making it work purely with nginx files. If you find one, please let me know.

[ApertureDevelopment]

Hello,

I am experiencing the same issue with the server replying with a 403 error, stating that the CSRF token is not valid for the domain. I have looked at the troubleshooting guide and can verify that all headers are set correctly, yet the error persists. I also tried setting the CSRF_TRUSTED_ORIGINS variable, yet that also does not seem to work. Strangely this does not affect the login, it only affects trying to update user data.

I am using Apache 2 as reverse proxy with the docker-compose installation.
The following headers were returned by /api/v3/admin/system/

Host: Matches domain
X-Forwarded-For: Matches my IP
X-Forwarded-Host: Matches domain
X-Forwarded-Server: Matches domain

Using the developer tools I could also verify that uppon sending a PATCH request the Host header is also set to the correct domain.

Solved it, Apache seems to not set the X-Forwarded-Proto header by itself.