kitchenowl Bug: Fails to login with OIDC and Authelia

Is this urgent?

No

What parts are affected

Frontend

What is the server version

v117

What is the client version

0.7.3

What platform are you using

Linux

What's the problem 🤔

If I try to login via OIDC, "nothing happens" (at least visibly in the browser).

The browser console log shows:

flutter_bootstrap.js:3 Loading from existing service worker.
flutter_bootstrap.js:3 Service worker already active.
flutter_bootstrap.js:1 Injecting <script> tag. Using callback.
household:1 <meta name="apple-mobile-web-app-capable" content="yes"> is deprecated. Please include <meta name="mobile-web-app-capable" content="yes">
socket.io/?EIO=4&transport=polling&sid=p4nZp3u9w_giwpA7AAAA:1  Failed to load resource: the server responded with a status of 400 ()
socket.io/?EIO=4&transport=polling&sid=p4nZp3u9w_giwpA7AAAA:1  Failed to load resource: the server responded with a status of 400 ()
api/auth/oidc?provider=custom:1  Failed to load resource: the server responded with a status of 401 ()

So, that suggests to me that it's received a perfectly expected first response and then just stopped.

On the authelia side, I see:

`time="2025-08-10T17:14:07-03:00" level=debug msg="Check authorization of subject username=derek groups=admins,dev ip=99.192.106.103 and object https://kitchenowl.pointerstop.ca/api/user (method GET)."

Which, again, looks perfectly normal. But then Authelia says nothing more…

If I try to Link my OIDC account under my profile, I get (from https://auth.pointerstop.ca/api/oidc/authorization?client_id=kitchenowl&response_type=code&scope=openid+profile+email&nonce=GpRqxQk02X9Ei3aZ&state=jUHCYht8ScmlRiwx&redirect_uri=https%3A%2F%2Fkitchenowl.pointerstop.ca%2F%2Fsignin%2Fredirect):

{"error":"invalid_request","error_description":"The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed. The 'redirect_uri' parameter does not match any of the OAuth 2.0 Client's pre-registered 'redirect_uris'."}

but that redirect_uri is exactly what's in the configuration.yml

Authelia is configured to authenticate users for another application without OIDC (because the other app doesn't support it), so I'm suspecting a conflict between the settings somewhere

Share your logs

Share your configuration

docker-compose.yml

networks: 
  proxy:
    name: proxy
    external: false

secrets:
  authelia_jwt_secret:
    file: $SECRETS_PATH/authelia/jwt_secret
  authelia_session_secret:
    file: $SECRETS_PATH/authelia/session_secret
  authelia_storage_encryption_key:
    file: $SECRETS_PATH/authelia/storage_encryption_key
  authelia_hmac_secret:
    file: $SECRETS_PATH/authelia/hmac_secret

services:
  traefik:
    image: traefik:latest
    container_name: traefik
    restart: unless-stopped
    command:
    - --api.insecure=true
    - --providers.docker
    - --entrypoints.web.address=:80
    - --entrypoints.websecure.address=:443
    - --entrypoints.websecure.forwardedHeaders.trustedIPs=172.0.0.0/8,198.168.2.0/24,127.0.0.1
    - --certificatesresolvers.letsencrypt.acme.email=${LE_EMAIL}
    - --certificatesresolvers.letsencrypt.acme.storage=/config/acme.json
    - --certificatesresolvers.letsencrypt.acme.tlschallenge=true
    - --log.filePath=/var/log/traefik.log
    - --providers.file.directory=/dynamic_config/
    - --providers.file.watch=true
    ports:
      - 8080:8080
      - 80:80
      - 443:443
    labels:
      - dhcp=true
      - traefik.enable=true
      - traefik.http.routers.traefik.rule=Host(`traefik.home`)
      ## Services - API
      - traefik.http.routers.traefik.service=api@internal
      ## Global redirect of EXTERNAL domains to HTTPS
      - traefik.http.routers.redirs.rule=HostRegexp(`^(.+\.)?pointerstop\.ca$`)
      - traefik.http.routers.redirs.entrypoints=web
      - traefik.http.routers.redirs.middlewares=redirect-to-https@docker
      - traefik.http.middlewares.redirect-to-https.redirectScheme.scheme=https
      - traefik.http.middlewares.redirect-to-https.redirectScheme.permanent=true
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /var/log/media-server:/var/log
      - ${CONFIG_PATH}/traefik:/config
      - ./dynamic_config:/dynamic_config
    networks:
      - proxy

  # Authelia (Lite) - Self-Hosted Single Sign-On and Two-Factor Authentication
  authelia:
    container_name: authelia
    image: authelia/authelia:latest
    restart: unless-stopped
    expose:
      - 9091
    networks: 
      - proxy
    volumes:
      - ./authelia:/config
    environment:
      - PUID=0
      - PGID=0
      - TZ=${TIME_ZONE}
      - AUTHELIA_IDENTITY_PROVIDERS_OIDC_HMAC_SECRET_FILE=/run/secrets/authelia_hmac_secret
      - AUTHELIA_IDENTITY_VALIDATION_RESET_PASSWORD_JWT_SECRET_FILE=/run/secrets/authelia_jwt_secret
      - AUTHELIA_SESSION_SECRET_FILE=/run/secrets/authelia_session_secret
      - AUTHELIA_STORAGE_ENCRYPTION_KEY_FILE=/run/secrets/authelia_storage_encryption_key
      - X_AUTHELIA_CONFIG_FILTERS=template
    secrets:
      - authelia_hmac_secret
      - authelia_jwt_secret
      - authelia_session_secret
      - authelia_storage_encryption_key
    labels:
      - traefik.enable=true
      ## HTTP Routers
      - traefik.http.routers.authelia.entrypoints=websecure
      - traefik.http.routers.authelia.rule=Host(`auth.pointerstop.ca`)
      - traefik.http.routers.authelia.tls=true
      - traefik.http.routers.authelia.tls.certresolver=letsencrypt
      ## HTTP Services
      - traefik.http.services.authelia-media-server.loadbalancer.server.port=9091
      ## Middlewares
      - traefik.http.routers.authelia.middlewares=rate-limit@file,secure-headers@file,authelia@docker
      - 'traefik.http.middlewares.authelia.forwardauth.address=http://authelia:9091/api/verify?rd=https://auth.pointerstop.ca'  # yamllint disable-line rule:line-length
      - 'traefik.http.middlewares.authelia.forwardauth.trustForwardHeader=true'
      - 'traefik.http.middlewares.authelia.forwardauth.authResponseHeaders=Remote-User,Remote-Groups,Remote-Name,Remote-Email'  # yamllint disable-line rule:line-length

  kitchenowl:
    container_name: kitchenowl
    image: tombursch/kitchenowl:latest
    restart: unless-stopped
    networks:
      - proxy
    labels:
      - traefik.enable=true
      - traefik.http.routers.kitchenowl.rule=Host(`kitchenowl.home`)
      - traefik.http.routers.kitchenowl.entrypoints=web
      - traefik.http.routers.kitchenowl-https.entrypoints=websecure
      - traefik.http.routers.kitchenowl-https.rule=Host(`kitchenowl.pointerstop.ca`)
      # - Sets TLS to true
      - traefik.http.routers.kitchenowl-https.tls=true
      - traefik.http.routers.kitchenowl-https.tls.certresolver=letsencrypt
    env_file:
      - ko.env
    volumes:
      - kitchenowl:/data

volumes:
  kitchenowl:

and in the Authelia configuration.yml:

identity_providers:
  oidc:
    jwks:
    - key: {{ secret "/config/oidc/private.pem" | mindent 10 "|" | msquote }}
    clients:
    - client_id: kitchenowl
      client_name: KitchenOwl
      client_secret: **************************
      public: false
      authorization_policy: one_factor 
      pre_configured_consent_duration: 1M # One month - change this to something you desire
      audience: []
      scopes:
          - openid
          - email
          - profile
      redirect_uris:
          - https://kitchenowl.pointerstop.ca/signin/redirect # Put the same value as FRONT_URL, appended with /signin/redirect
          - kitchenowl:/signin/redirect
      response_modes:
      token_endpoint_auth_method: client_secret_post

Aug 10 '25 21:08 auspex

Curiouser and curiouser.

I was beginning to suspect that it was related to the fact that I was already logged into Authelia, but nothing changed when I actually logged out from Authelia directly. But I tried again, on my phone, yesterday, and I logged in successfully via Authelia. It did, however, create a new account because I'd not thought to add an email address to my original account. Then I logged in manually to the original account, deleted the new one, and then "Linked" my account to OIDC. That said it worked: but the app hung with "working" spinner. When I closed and reopened the app it would NOT let me login via OIDC.

I was able to login via OIDC (on the phone) again this morning, once, but then not again. I have NOT however, ever been able to login via OIDC from a Vivaldi browser session. I'll try something more mainstream.

Aug 13 '25 21:08 auspex

Login via OIDC from Firefox returns the same:

{"error":"invalid_request","error_description":"The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed. The 'redirect_uri' parameter does not match any of the OAuth 2.0 Client's pre-registered 'redirect_uris'."}

Aug 14 '25 18:08 auspex

I've tracked down one problem: FRONT_URL must not have a trailing slash...

Now I'm not getting the error when I initially login via OIDC, or if I logout directly in Authelia.

However, if I logout from my profile page in KitchenOwl, I am redirected to $FRONT_URL/signin, from where I can only login by providing username and password. BUT if I then navigate to $FRONT_URL, which redirects me to the same $FRONT_URL/signin page, OIDC login works!

Aug 14 '25 19:08 auspex

Hey thanks for working your way through this! So are there multiple bugs here? Front URL cannot have a trailing / because the redirect link won't be correct and you also don't see the oidc login button after logging out and need to refresh the page?

Aug 14 '25 19:08 TomBursch

Yes, that's it (though I'm not certain that the trailing slash on FRONT_URL is really a bug—certainly not on KitchenOwl's end. It's just Authelia needing the redirect_uri to be an exact match, so no doubled slashes. But that's definitely worth documenting.

The second is not that I can't see the OIDC login button, but that it has no effect until I back out to $FRONT_URL

Aug 15 '25 01:08 auspex

Hi.

I am also using authelia and see the same issue. For example, after logging out, the "Sign in with OIDC" button on the /signin page has no effect.

When clicking the button, I see the following requests in the Network tab of the browser's console:

GET /api/auth/oidc?provider=custom => 401 msg: "Token has expired"
GET /api/health/<some-hash> => 200 OK
GET /api/auth/refresh => 401 msg: "Token has expired"

The first and third request send an authorization Bearer token and authelia_session cookie. Which I think is a bit odd, after logout these should have been removed from the session, no?

When reloading the page, another GET /api/auth/refresh request is sent, with the same response.

However, after reloading the page, the button successfully triggers the openid login flow as the GET /api/auth/oidc?provider=custom request now returns some JSON data with status code 200. This time, there was no Authorization header sent.

I was able to reproduce this:

logout
try to sign in with OIDC => 401
resend the GET /api/auth/oidc?provider=custom request from the browser network tab, but removing the Authorization header => 200 OK { login_url: ..., nonce: ..., state: ...}

Nov 16 '25 16:11 avdv

I just pushed a PR to fix this: https://github.com/TomBursch/kitchenowl/pull/925

The first and third request send an authorization Bearer token and authelia_session cookie. Which I think is a bit odd, after logout these should have been removed from the session, no?

Actually, the authelia_session cookie should not be removed, since the user is not logged out from the IdP but just kitchenowl.

Nov 23 '25 16:11 avdv