I just had the same issue, the workaround was use Chrome instead of Firefox, and use the HTTPS port instead of HTTP. IE https://172.16.117.253:9443/if/flow/initial-setup/

Which one of those changes sorted it I can't say, but it works now.

Struggling with a very similar thing atm...
I have a fresh setup where initial setup worked fine, but when I attempt to use the enrollment flow I get the same message. Regular login with the akadmin user works though.

This is the same no matter the browser, incognito or otherwise. I installed using the v2023.10.6 helm chart on Kubernetes, with only an http port (80) exposed on the container. Ingress acts as HTTPS termination.

had a similar issue while still had an additional basic auth middleware applied. after removal it worked.

its strange, launching through authentik home works fine, but opening from an incognito window doesn't.

Same applies me too, I just installed it to try it out but giving me the same error. Cannot setup.

Looks like something is messing up the ui, checked the network and nothing is wrong but the ui doesn't seem to respond how it should, probably because of the extensions I installed.

Tried in mozilla and it works.

Same issue here. Fresh installation using last version 2024.2.2 and accessing Authentik redirecting me to the login default page if/flow/default-authentication-flow/?next=%2F and then show an error in both UI and logs.

authentik-server      | {"action": "system_exception", "auth_via": "unauthenticated", "client_ip": "172.29.125.27", "context": {"http_request": {"args": {"next": "/"}, "method": "GET", "path": "/api/v3/flows/exe
cutor/default-authentication-flow/", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0"}, "message": "Traceback (most recent call last):\n  File \"/ak-root/venv/lib/
python3.12/site-packages/rest_framework/views.py\", line 497, in dispatch\n    self.initial(request, *args, **kwargs)\n  File \"/ak-root/venv/lib/python3.12/site-packages/sentry_sdk/integrations/django/__init__.
py\", line 312, in sentry_patched_drf_initial\n    return old_drf_initial(self, request, *args, **kwargs)\n           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/ak-root/venv/lib/python3.12/site-p
ackages/rest_framework/views.py\", line 414, in initial\n    self.perform_authentication(request)\n  File \"/ak-root/venv/lib/python3.12/site-packages/rest_framework/views.py\", line 324, in perform_authenticati
on\n    request.user\n  File \"/ak-root/venv/lib/python3.12/site-packages/rest_framework/request.py\", line 227, in user\n    self._authenticate()\n  File \"/ak-root/venv/lib/python3.12/site-packages/rest_framew
ork/request.py\", line 380, in _authenticate\n    user_auth_tuple = authenticator.authenticate(self)\n                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/authentik/api/authentication.py\", line 99,
 in authenticate\n    user = bearer_auth(auth)\n           ^^^^^^^^^^^^^^^^^\n  File \"/authentik/api/authentication.py\", line 37, in bearer_auth\n    user = auth_user_lookup(raw_header)\n           ^^^^^^^^^^^
^^^^^^^^^^^^^^^^^\n  File \"/authentik/api/authentication.py\", line 49, in auth_user_lookup\n    auth_credentials = validate_auth(raw_header)\n                       ^^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/authent
ik/api/authentication.py\", line 29, in validate_auth\n    raise AuthenticationFailed(\"Unsupported authentication type\")\nrest_framework.exceptions.AuthenticationFailed: Unsupported authentication type"}, "dom
ain_url": "sub.domain.tld", "event": "Created Event", "host": "sub.domain.tld", "level": "info", "logger": "authentik.events.models", "pid": 84, "request_id": "0beeff0353c04ee78a57dd6bbb6
4a37c", "schema_name": "public", "timestamp": "2024-04-10T10:03:40.324965", "user": {"email": "", "is_anonymous": true, "pk": 1, "username": "AnonymousUser"}}
authentik-server      | {"auth_via": "unauthenticated", "domain_url": "sub.domain.tld", "event": "Task published", "host": "sub.domain.tld", "level": "info", "logger": "authentik.root.cel
ery", "pid": 84, "request_id": "0beeff0353c04ee78a57dd6bbb64a37c", "schema_name": "public", "task_id": "1f069fba9c53432b8214437c82aa8a6a", "task_name": "authentik.events.tasks.event_notification_handler", "times
tamp": "2024-04-10T10:03:40.346281"}

Same issue here. Error on 2023.10.7 and updating to lastest version 2024.2.2 change nothing. The error happens on every application using oauth or oidc. (like komga,Statping or argocd). The logging work if my users are already login in authentik, but cannot login otherwise.
Accessing applications is redirecting me to the login default page if/flow/default-authentication-flow/?next=%2F and then show an error in both UI and logs.

I'm also in the same boat here:

Fresh setup, the initial setup can't even kick off.
And once you get the error about request denied, it's persistent and never goes away.

Any update/idea yet why?
Been trying a whole week all kinds of ways, but this seems to be a bug.
I'm about to give up on Authentik and change to something else.

With the latest Authentik, Docker and Docker Compose version the "Flow does not apply to current user." can be resolved by correcting the providers authentication flow from the incorrect default-source-authentication to default-authentication-flow.

Visual image of this is below:

My docker-compose.yml file:

# Installation: https://hub.docker.com/r/beryju/authentik

version: '3.9'
services:
  server:
    image: beryju/authentik:2024.2
    container_name: authentik
    restart: unless-stopped
    command: server
    user: "root"
    environment:
      - AUTHENTIK_REDIS__HOST=${AUTHENTIK_REDIS__HOST}
      - AUTHENTIK_POSTGRESQL__HOST=${AUTHENTIK_POSTGRESQL__HOST}
      - AUTHENTIK_POSTGRESQL__USER=${AUTHENTIK_POSTGRESQL__USER}
      - AUTHENTIK_POSTGRESQL__NAME=${AUTHENTIK_POSTGRESQL__NAME}
      - AUTHENTIK_POSTGRESQL__PASSWORD=${AUTHENTIK_POSTGRESQL__PASSWORD}
      - AUTHENTIK_ERROR_REPORTING__ENABLED=${AUTHENTIK_ERROR_REPORTING__ENABLED}
      - AUTHENTIK_SECRET_KEY=${AUTHENTIK_SECRET_KEY}
    volumes:
      - /opt/appdata/authentik/media:/media
      - /opt/appdata/authentik/custom-templates:/templates
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - 9815:9000
      - 9816:9443
    depends_on:
      - postgresql-authentik
      - redis-authentik
    networks:
      - proxy

  worker:
    image: beryju/authentik:2024.2
    container_name: authentik_worker
    restart: unless-stopped
    command: worker
    user: "root"
    environment:
      - AUTHENTIK_REDIS__HOST=${AUTHENTIK_REDIS__HOST}
      - AUTHENTIK_POSTGRESQL__HOST=${AUTHENTIK_POSTGRESQL__HOST}
      - AUTHENTIK_POSTGRESQL__USER=${AUTHENTIK_POSTGRESQL__USER}
      - AUTHENTIK_POSTGRESQL__NAME=${AUTHENTIK_POSTGRESQL__NAME}
      - AUTHENTIK_POSTGRESQL__PASSWORD=${AUTHENTIK_POSTGRESQL__PASSWORD}
      - AUTHENTIK_ERROR_REPORTING__ENABLED=${AUTHENTIK_ERROR_REPORTING__ENABLED}
      - AUTHENTIK_SECRET_KEY=${AUTHENTIK_SECRET_KEY}
    # `user: root` and the docker socket volume are optional.
    # See more for the docker socket integration here:
    # https://goauthentik.io/docs/outposts/integrations/docker
    # Removing `user: root` also prevents the worker from fixing the permissions
    # on the mounted folders, so when removing this make sure the folders have the correct UID/GID
    # (1000:1000 by default)
    volumes:
      - /opt/appdata/authentik/media:/media
      - /opt/appdata/authentik/certs:/certs
      - /var/run/docker.sock:/var/run/docker.sock
      - /opt/appdata/authentik/custom-templates:/templates
    depends_on:
      - postgresql-authentik
      - redis-authentik
    networks:
      - proxy

  postgresql-authentik:
    image: postgres:16-alpine3.19
    container_name: postgresql-authentik
    restart: unless-stopped
    healthcheck:
      test:
        [
          'CMD-SHELL',
          'pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}'
        ]
      start_period: 20s
      interval: 30s
      retries: 5
      timeout: 5s
    environment:
      - PUID='1000'
      - PGID='1000'
      - POSTGRES_USER=${AUTHENTIK_POSTGRESQL__USER}
      - POSTGRES_DB=${AUTHENTIK_POSTGRESQL__NAME}
      - POSTGRES_PASSWORD=${AUTHENTIK_POSTGRESQL__PASSWORD:?database password required}
    volumes:
      - authentik-postgresql-volume:/var/lib/postgresql/data
    ports:
      - 5432:8080
    networks:
      - proxy

  redis-authentik:
    image: redis:alpine3.19
    container_name: redis-authentik
    restart: unless-stopped
    healthcheck:
      test: [ 'CMD-SHELL', 'redis-cli ping | grep PONG' ]
      start_period: 20s
      interval: 30s
      retries: 5
      timeout: 3s
    environment:
      - PUID='1000'
      - PGID='1000'
    volumes:
      - authentik-redis-volume:/data
    ports:
      - 6379:6379
    networks:
      - proxy

volumes:
  authentik-postgresql-volume: {}
  authentik-redis-volume: {}

networks:
  proxy:
    driver: bridge
    external: true

At least this has resolved the issue for myself. I hope this helps everyone else, have a great day!

With the latest Authentik, Docker and Docker Compose version the "Flow does not apply to current user." can be resolved by correcting the providers authentication flow from the incorrect default-source-authentication to default-authentication-flow.

Visual image of this is below:

My docker-compose.yml file:

# Installation: https://hub.docker.com/r/beryju/authentik

version: '3.9'
services:
  server:
    image: beryju/authentik:2024.2
    container_name: authentik
    restart: unless-stopped
    command: server
    user: "root"
    environment:
      - AUTHENTIK_REDIS__HOST=${AUTHENTIK_REDIS__HOST}
      - AUTHENTIK_POSTGRESQL__HOST=${AUTHENTIK_POSTGRESQL__HOST}
      - AUTHENTIK_POSTGRESQL__USER=${AUTHENTIK_POSTGRESQL__USER}
      - AUTHENTIK_POSTGRESQL__NAME=${AUTHENTIK_POSTGRESQL__NAME}
      - AUTHENTIK_POSTGRESQL__PASSWORD=${AUTHENTIK_POSTGRESQL__PASSWORD}
      - AUTHENTIK_ERROR_REPORTING__ENABLED=${AUTHENTIK_ERROR_REPORTING__ENABLED}
      - AUTHENTIK_SECRET_KEY=${AUTHENTIK_SECRET_KEY}
    volumes:
      - /opt/appdata/authentik/media:/media
      - /opt/appdata/authentik/custom-templates:/templates
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - 9815:9000
      - 9816:9443
    depends_on:
      - postgresql-authentik
      - redis-authentik
    networks:
      - proxy

  worker:
    image: beryju/authentik:2024.2
    container_name: authentik_worker
    restart: unless-stopped
    command: worker
    user: "root"
    environment:
      - AUTHENTIK_REDIS__HOST=${AUTHENTIK_REDIS__HOST}
      - AUTHENTIK_POSTGRESQL__HOST=${AUTHENTIK_POSTGRESQL__HOST}
      - AUTHENTIK_POSTGRESQL__USER=${AUTHENTIK_POSTGRESQL__USER}
      - AUTHENTIK_POSTGRESQL__NAME=${AUTHENTIK_POSTGRESQL__NAME}
      - AUTHENTIK_POSTGRESQL__PASSWORD=${AUTHENTIK_POSTGRESQL__PASSWORD}
      - AUTHENTIK_ERROR_REPORTING__ENABLED=${AUTHENTIK_ERROR_REPORTING__ENABLED}
      - AUTHENTIK_SECRET_KEY=${AUTHENTIK_SECRET_KEY}
    # `user: root` and the docker socket volume are optional.
    # See more for the docker socket integration here:
    # https://goauthentik.io/docs/outposts/integrations/docker
    # Removing `user: root` also prevents the worker from fixing the permissions
    # on the mounted folders, so when removing this make sure the folders have the correct UID/GID
    # (1000:1000 by default)
    volumes:
      - /opt/appdata/authentik/media:/media
      - /opt/appdata/authentik/certs:/certs
      - /var/run/docker.sock:/var/run/docker.sock
      - /opt/appdata/authentik/custom-templates:/templates
    depends_on:
      - postgresql-authentik
      - redis-authentik
    networks:
      - proxy

  postgresql-authentik:
    image: postgres:16-alpine3.19
    container_name: postgresql-authentik
    restart: unless-stopped
    healthcheck:
      test:
        [
          'CMD-SHELL',
          'pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}'
        ]
      start_period: 20s
      interval: 30s
      retries: 5
      timeout: 5s
    environment:
      - PUID='1000'
      - PGID='1000'
      - POSTGRES_USER=${AUTHENTIK_POSTGRESQL__USER}
      - POSTGRES_DB=${AUTHENTIK_POSTGRESQL__NAME}
      - POSTGRES_PASSWORD=${AUTHENTIK_POSTGRESQL__PASSWORD:?database password required}
    volumes:
      - authentik-postgresql-volume:/var/lib/postgresql/data
    ports:
      - 5432:8080
    networks:
      - proxy

  redis-authentik:
    image: redis:alpine3.19
    container_name: redis-authentik
    restart: unless-stopped
    healthcheck:
      test: [ 'CMD-SHELL', 'redis-cli ping | grep PONG' ]
      start_period: 20s
      interval: 30s
      retries: 5
      timeout: 3s
    environment:
      - PUID='1000'
      - PGID='1000'
    volumes:
      - authentik-redis-volume:/data
    ports:
      - 6379:6379
    networks:
      - proxy

volumes:
  authentik-postgresql-volume: {}
  authentik-redis-volume: {}

networks:
  proxy:
    driver: bridge
    external: true

At least this has resolved the issue for myself. I hope this helps everyone else, have a great day!

this is not the same issue we are reporting.
You already got "in" Authentik. We can't even do the initial admin account create immediately after Authentik is spin up.
It locks completely from the first minute. And once it's locked, it remains like this.
The only way to continue is docker compose down, remove volume and docker compose up again to have another try and to have the same error over and over.

It's happening since the last 2 or 3 released afaik.

@codeagencybe Ah, understood. That is a strange issue.

I was also in the same boat yesterday. I found a temporary workaround, so it is possible to log in as admin without completing the initial-setup step due to this bug(?).

The solution below is sourced verbatim from their Troubleshooting: Login page.

To create the key, run the following command:

docker compose run --rm server create_recovery_key 10 akadmin

For Kubernetes, run

kubectl exec -it deployment/authentik-worker -c authentik -- ak create_recovery_key 10 akadmin

or, for CLI, run

ak create_recovery_key 10 akadmin

This will output a link, that can be used to instantly gain access to authentik as the user specified above. The link is valid for amount of years specified above, in this case, 10 years.

When you are inside click the following:

Admin Interface (navbar) > Directory (sidebar) > Users (option in dropdown) > akadmin (link) > User Info (left-side section) > Set Password (button)

When your password is set, you should be able to log in as akadmin.

I managed to get my issue solved by changing the LISTEN HTTP flags as following:

AUTHENTIK_LISTEN__HTTP=authentik-server:8000
AUTHENTIK_LISTEN__HTTPS=authentik-server:8443

I think the problem was coming from a port conflict with Portainer who occupies ports 8000, 9000 and 9443 by default.
I already changed the ports for Authentik to 8000 and 8443 but for some reason I found in the logs parts of "output" trying to do something on port 9000 which is obviously going to Portainer container and failing.

After I set these 2 extra params, matching the same ports on COMPOSE_PORT, the problem was solved.

Also, updating to image version 2024.4.0 fixed some other issues.

At the end of the day, I ended up getting around this by using the AUTHENTIK_BOOTSTRAP_ variables to register a user during image creation. That worked, but I ran into so many other issues with getting authentication actually working that I just gave up and left it alone for a while. Trying again with all of this this weekend...

fresh install of authentik and can confirm this is still an issue where a fresh install doesn't let you setup a user and then permanently locks you out unless you drop the entire DB or volume the db is on to try again and repeat this loop. Using the standard instructions of just making the compose, running it, and attempting the initial flow at /if/flow/initial-setup/ on either https or http on either firefox or chrome.

This is a showstopper bug which really puts me off to adopting this in my enterprise if there's a gamebreaking issue with the most vanilla setup in my homelab (that's been open since january it looks like?), as a dev / devops engineer I know resources are limited and there's always something more pressing in the backlog but i literally can't sell my org on adopting this if the default docker-compose instructions simply don't work to demo it!

So if you are behind a reverse proxy much like traefik and are setting up your subdomains like most videos tell you, authentik.example.com then you need to check a couple of things. I just got this working with the latest pin with traefik after days of troubleshooting the same exact error.

I run portainer in my setup, so i had to setup these env variables (as listed above so thanks @codeagencybe )

AUTHENTIK_LISTEN__HTTP=authentik-server:8000
AUTHENTIK_LISTEN__HTTPS=authentik-server:8443

If you are setting an explicit AUTHENTIK_COOKIE_DOMAIN env variable, try without it. see docs.

Here's my authentik-server config

authentik-server:
    image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-latest}
    container_name: authentik-server
    restart: unless-stopped
    command: server
    environment:
      AUTHENTIK_REDIS__HOST: redis
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik}
      AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik}
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
      AUTHENTIK_HOST_BROWSER: https://authentik.${PROJECT_HOSTNAME}

    volumes:
      - ${DEFAULT_CONTAINER_DATA_LOCATION}/Authentik/media:/media
      - ${DEFAULT_CONTAINER_DATA_LOCATION}/Authentik/custom-templates:/templates
    networks:
      - zauthentik # i had to do zauthentik because i had network priority issues so this makes it last for my auth backend
      - homelab
    env_file:
      - ../.env
    ports:
      - 8000:8000
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.authentik-server.rule=Host(`authentik.${PROJECT_HOSTNAME}`)"
      - "traefik.http.routers.authentik-server.entrypoints=https" # or i have seen a lot of people call this websecure
      - "traefik.http.routers.authentik-server.tls=true"
      - "traefik.http.routers.authentik-server.tls.certresolver=${TRAEFIK_TLS_CERTRESOLVER}"
      - "traefik.http.routers.authentik-server.service=authentik-svc"
      - "traefik.http.services.authentik-svc.loadBalancer.server.port=8000"
    depends_on:
      - postgresql
      - redis
      - traefik
    profiles:
      - all
      - authentik
      - traefik

and then here's my dynamic configuration:

http:
  middlewares:
    # https://github.com/goauthentik/authentik/issues/2366
    middlewares-authentik:
      forwardAuth:
        address: http://authentik-server:8000/outpost.goauthentik.io/auth/traefik # authentik-server matches the name of the container or service i think
        trustForwardHeader: true
        authResponseHeaders:
          - X-authentik-username
          - X-authentik-groups
          - X-authentik-email
          - X-authentik-name
          - X-authentik-uid
          - X-authentik-jwt
          - X-authentik-meta-jwks
          - X-authentik-meta-outpost
          - X-authentik-meta-provider
          - X-authentik-meta-app
          - X-authentik-meta-version

Doing all that finally allowed me to get in. Ultimately i think the COOKIE_DOMAIN thing is what did it for me. I figured it out because i could get in fine from localhost:8000 but when i tried to go reverse proxy it was just failing. So i knew something was up with the way the hostname was getting parsed or something.

When i originally checked my request headers, i saw that the domain the access token was setting was localhost and wasn't my FQDN for my authentik instance in my homelab.

I was also in the same boat yesterday. I found a temporary workaround, so it is possible to log in as admin without completing the initial-setup step due to this bug(?).

The solution below is sourced verbatim from their Troubleshooting: Login page.

To create the key, run the following command:

docker compose run --rm server create_recovery_key 10 akadmin

For Kubernetes, run

kubectl exec -it deployment/authentik-worker -c authentik -- ak create_recovery_key 10 akadmin

or, for CLI, run

ak create_recovery_key 10 akadmin

This will output a link, that can be used to instantly gain access to authentik as the user specified above. The link is valid for amount of years specified above, in this case, 10 years.

When you are inside click the following:

Admin Interface (navbar) > Directory (sidebar) > Users (option in dropdown) > akadmin (link) > User Info (left-side section) > Set Password (button)

When your password is set, you should be able to log in as akadmin.

this doesn't seem to work (anymore?). I get the URL generated correctly, visit it, and it looks like it loads the app for a split second before the frontend realizes the user isn't authed / created properly / some other error, and it kicks me back out to this page

the URL then changes to /if/flow/default-authentication-flow/?next=%2Fif%2Fuser%2F

to re-iterate, this is on a fresh install where i can't get completing visiting the URL if/flows/initial-setup to work. I've tried after i lock myself out by entering any info or even wrong info if/flows/initial-setup or before i even visit if/flows/initial-setup, the behavior is the same.

If you're in docker, make sure you don't have any residual volumes or DB data and try incognito mode too. Authentik has some stuff that may be cached.

Yeah i'm just straight up deleting the docker volume everytime that has the DB and watching it rerun all the migrations etc.

Wasn't trying with incognito before, forgot they'd store cookies, but am trying it now to no avail just the same.

Thanks for the help.

of note, i'm not running any reverse proxy in front of it, and i do see people talking about setting these in their comments above (i've changed the values to match my compose)

AUTHENTIK_LISTEN__HTTP=server:9003
AUTHENTIK_LISTEN__HTTPS=server:9445

but when i add these in, my app is actually just not reachable at all.

using this compose that i grabbed from the official instructions, the main thing i changed was just the ports basically.

---
version: "3.4"

services:
  postgresql:
    image: docker.io/library/postgres:12-alpine
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}"]
      start_period: 20s
      interval: 30s
      retries: 5
      timeout: 5s
    volumes:
      - database:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: ${PG_PASS:?database password required}
      POSTGRES_USER: ${PG_USER:-authentik}
      POSTGRES_DB: ${PG_DB:-authentik}
    env_file:
      - .env
  redis:
    image: docker.io/library/redis:alpine
    command: --save 60 1 --loglevel warning
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "redis-cli ping | grep PONG"]
      start_period: 20s
      interval: 30s
      retries: 5
      timeout: 3s
    volumes:
      - redis:/data
  server:
    image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-2024.4.2}
    restart: unless-stopped
    command: server
    environment:
      AUTHENTIK_REDIS__HOST: redis
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik}
      AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik}
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
    volumes:
      - ./media:/media
      - ./custom-templates:/templates
    env_file:
      - .env
    ports:
      - "${COMPOSE_PORT_HTTP:-9003}:9000"
      - "${COMPOSE_PORT_HTTPS:-9445}:9443"
    depends_on:
      - postgresql
      - redis
  worker:
    image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-2024.4.2}
    restart: unless-stopped
    command: worker
    environment:
      AUTHENTIK_REDIS__HOST: redis
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik}
      AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik}
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
    # `user: root` and the docker socket volume are optional.
    # See more for the docker socket integration here:
    # https://goauthentik.io/docs/outposts/integrations/docker
    # Removing `user: root` also prevents the worker from fixing the permissions
    # on the mounted folders, so when removing this make sure the folders have the correct UID/GID
    # (1000:1000 by default)
    user: root
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./media:/media
      - ./certs:/certs
      - ./custom-templates:/templates
    env_file:
      - .env
    depends_on:
      - postgresql
      - redis

volumes:
  database:
    driver: local
  redis:
    driver: local

weird that when i add those two variables to my env file, i'm not able to connect to the app's frontend at all, so i've just removed those and i don't specify a compose value either. the app seems to boot successfully from the logs

Maybe give this .env a look. Compare it to yours maybe. That's what I use.

Also possibly give their docs a look.

https://homemediadocker.github.io/Home-Media-Docker/docs/authentik-sso

Note that this container uses an internal network called homelab and zauthentik. This is because the networks for docker get appended in alphabetical order based on priority by default (pretty sure).

I noticed yours didn't have a network defined so it should just use the default docker network

Also this one has the ports commented out too for Authentik - this is because it is behind a reverse proxy.

AUTHENTIK_LISTEN__HTTP=server:9003
AUTHENTIK_LISTEN__HTTPS=server:9445

but when i add these in, my app is actually just not reachable at all.

Try using the ports it listens to internally, 9000 & 9443. Had same issue then I realized the variables apple internally not external to docker where there's a port forward.

I'm having the same issue... i can get in via recovery link but no one else can log in.

I made no changes (that I know of) and am running the latest version 2024..4.2 .. I woke up the next day and couldn't log in.

Bashing my head trying things... i'm using nginx proxy manger in front of authentik.

Everything was just fine and boom... this happened.

docker-compose.pdf

and this is in my .env file

COMPOSE_PORT_HTTP=8080
COMPOSE_PORT_HTTPS=4443

Authentik Version to Pull

ATHENTIK_TAG=2024.4.2

Resolved my issue... so stupid.. but I still don't know how it happened..

This worked for me:
Removed/deleted the docker and the volumes.
The secret keys that I generated with Bitwarden contained special characters as !@#%^&*
It seems like it dosn't like that. So I created new keys without those characters.
Redeployed the docker and it worked. Created an admin user and are now in the program.

This worked for me: Removed/deleted the docker and the volumes. The secret keys that I generated with Bitwarden contained special characters as !@#%^&* It seems like it dosn't like that. So I created new keys without those characters. Redeployed the docker and it worked. Created an admin user and are now in the program.

that seems to have been the issue for me, i had a "+" in my secretkey for authentik and it caused all this mayhem. Removing all special characters and i can happy path install it from scratch per the documentation!

This worked for me: Removed/deleted the docker and the volumes. The secret keys that I generated with Bitwarden contained special characters as !@#%^&* It seems like it dosn't like that. So I created new keys without those characters. Redeployed the docker and it worked. Created an admin user and are now in the program.

that seems to have been the issue for me, i had a "+" in my secretkey for authentik and it caused all this mayhem. Removing all special characters and i can happy path install it from scratch per the documentation!

Thank you this was the whole problem for me. Default installation instructions allow for illegal characters in the key. Removing '+' and redeploying fixed it.

Here's a revised line for the Installation instructions:

echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -dc 'a-zA-Z0-9' | tr -d '\n')" >> .env

Here's a revised line for the Installation instructions:

echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -dc 'a-zA-Z0-9' | tr -d '\n')" >> .env

Just ran into this on a fresh install, the docs really need to be updated!

https://docs.goauthentik.io/docs/installation/docker-compose

Still an issue for me, even after updating the secret key and redeploying...

As a workaround you can use https://docs.goauthentik.io/docs/installation/automated-install to set akadmin email and password and just login on https://<your ip/host>:9443

ATHENTIK_TAG=2024.4.2

Thanks so much, fixed my issue. according to logs 2024.6.1 appears not to have run the django migration properly, since when 2024.4.2 spun up the worker immediately had to apply a bunch of migrations.

Getting the same problem following official installation guide on Docker Compose. Can't even do the first login. This is a real showstopper for me.