Unable to get Authentik OIDC working

[puhtahtoe]

Description

I'm trying to set up Authentik OIDC with Homepage but I'm having some trouble.

After attempting login, I'm seeing an "OAUTH_CALLBACK_ERROR" in the URL bar and in the logs.

The Homepage logs are also showing "invalid_client (Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method))"

Authentik is reporting a successful application authorization in its logs.

Based on checking the network tab in the browser tools, I can see that the redirect to Authentik happens then Authentik redirects back to Homepage with a code but then Homepage redirects to /api/auth/error?error=OAuthCallback

I have Authentik configured to accept any redirect URI right now to eliminate that as a possible problem.

homepage version

v2.4.0

Installation method

Docker

Configuration

I'm using Komodo for managing the container.

networks:
  default:
    external: true
    name: utilities_network

services:

  homepage:
    image: ghcr.io/gethomepage/homepage:latest
    container_name: homepage
    restart: unless-stopped
    env_file:
      - ./.env
    ports:
      - 3002:3000
    volumes:
      - /${container_root}/homepage/config:/app/config # Make sure your local config directory exists
      - /${container_root}/homepage/images:/app/public/images
      - /${container_root}/homepage/icons:/app/public/icons


HOMEPAGE_ALLOWED_HOSTS=home.domain.com
HOMEPAGE_AUTH_ENABLED=true
HOMEPAGE_AUTH_SECRET=Kr7SirLUdKuP9...
HOMEPAGE_EXTERNAL_URL=https://home.domain.com
HOMEPAGE_OIDC_ISSUER=https://auth.otherdomain.com/application/o/homepage/
HOMEPAGE_OIDC_CLIENT_ID=ZnN1EO...
HOMEPAGE_OIDC_CLIENT_SECRET=QfQa...
HOMEPAGE_OIDC_AUTO_LOGIN=false
LOG_LEVEL=debug

Container Logs

homepage | 2026-09-19T22:54:38.558749487Z [2026-09-19T22:54:38.557Z] debug: CREATE_STATE
homepage | 2026-09-19T22:54:38.571371828Z [2026-09-19T22:54:38.570Z] debug: CREATE_PKCECODEVERIFIER
homepage | 2026-09-19T22:54:38.574308021Z [2026-09-19T22:54:38.573Z] debug: CREATE_NONCE
homepage | 2026-09-19T22:54:38.578303302Z [2026-09-19T22:54:38.577Z] debug: GET_AUTHORIZATION_URL
homepage | 2026-09-19T22:54:38.878280785Z [2026-09-19T22:54:38.877Z] error: OAUTH_CALLBACK_ERROR: invalid_client (Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method))

Browser Logs

The browser console does show two instances of the following error before even attempting login:
site.webmanifest?v=4:1 Manifest: Line: 1, column: 1, Syntax error.

I can't share the exact logs due to the URLs containing my personal information but I can see Homepage redirecting to Authentik and Authentik redirecting back to Homepage with a code and a state.

Troubleshooting

I did find this other discussion - #7068

The symptoms seem very similar to my issue however, I tried the solution to that post and it did not fix my problem.

[felipebridge]

The debug lines (CREATE_STATE, CREATE_PKCECODEVERIFIER, GET_AUTHORIZATION_URL) are Auth.js's OIDC flow, and the fact that Authentik logs a successful authorization but Homepage still fails means the break is specifically at the token exchange — Homepage's backend calling Authentik's /token endpoint with code + client_id + client_secret, and Authentik rejecting the client credentials themselves (not the code, not PKCE). That narrows it to two very common causes:

1. Client type mismatch in Authentik. The OAuth2/OIDC Provider has a "Client type" setting — Confidential vs Public. If it's set to Public, Authentik doesn't expect a client_secret in the token request at all and will reject the exchange with invalid_client even though the authorize step (which doesn't need the secret) succeeds. Since Homepage's flow is server-side and does send a secret, the provider needs to be Confidential.

2. The secret itself doesn't match exactly. This is the more common one in practice: Authentik's provider list view often shows a truncated secret, and copying from there instead of the full provider detail page grabs a partial value. Also worth checking your .env file directly for a stray leading/trailing quote or whitespace around HOMEPAGE_OIDC_CLIENT_SECRET — Docker's env_file does not strip quotes the way a shell would, so HOMEPAGE_OIDC_CLIENT_SECRET="abc123" with literal quotes in the file ends up sending those quote characters as part of the secret, which silently breaks client auth exactly like this (authorize step doesn't care, token exchange does).

I'd check #1 first (quick to verify in the Authentik provider settings), then re-copy the secret fresh from the provider's detail page into a .env line with no quotes.

[puhtahtoe]

@dosu

Here's a screenshot from the Authentik provider config showing Client Type Confidential and the first part of the Client Secret (note the cursor at the beginning of the Client Secret field)

Here's a screenshot showing the end of the Client Secret in Authentik (note the cursor at the end of the Client Secret field)

Here's a screenshot of my configuration in Komodo showing the env vars setup where you can see that the beginnings and ends of the Client ID and Client Secret match what is in Authentik.

[dosubot[bot]]

Hi @puhtahtoe! I'm Dosu and I'm helping the homepage team.

The "invalid_client / Client authentication failed" message is a different failure from discussion #7068 (that one was a JWT signing algorithm mismatch, RS256 vs HS256). Yours happens at the token endpoint, where Homepage sends the client ID and secret to Authentik to exchange the authorization code for tokens [1] — and Authentik is rejecting those credentials. Since Authentik logs a successful authorization and you're getting a code and state back, the redirect URI isn't the problem here.

The usual culprits are on the Authentik provider side: make sure the provider's client type is Confidential (a public client won't accept a client secret at all, which produces exactly this error), re-copy the Client ID and Secret straight from the provider page into your .env in case a character was dropped or the secret was rotated, and confirm HOMEPAGE_OIDC_ISSUER points at the application slug tied to that same provider, since Authentik scopes credentials per-provider.

Can you tell me which client type your Authentik OAuth2 provider is set to, and whether regenerating the secret fresh and updating .env changes anything?

Written by @dosu, approved by shamoon

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[puhtahtoe]

I have confirmed that the provider in Authentik is configured as Confidential and I have confirmed that no characters are being accidentally truncated in setting the env vars. I know the Issuer must be fine since the OIDC flow wouldn't be able to get as far as it does without information obtained via the Issuer.

[dosubot[bot]]

That rules out two of the three usual suspects. Homepage's NextAuth config doesn't set a client override or token_endpoint_auth_method [1], so it falls back to the OAuth library's default of client_secret_basic — client ID and secret go out as an HTTP Basic Authorization header on the token request rather than in the POST body. If that header never arrives intact at Authentik, you get exactly this: a clean authorize step, a valid code, then rejected credentials at exchange, even with a correct secret and a Confidential client.

So the remaining variable is how the credentials travel, not what they are. Anything sitting between Homepage's backend and https://auth.otherdomain.com/application/o/homepage/token/ — a reverse proxy, WAF, or an Authentik outpost — that strips or rewrites the Authorization header would cause this, and it wouldn't affect the browser-facing /authorize redirect since that request carries no such header. I couldn't verify Authentik's default auth method from their docs in this session, so treat this as a hypothesis rather than a confirmed cause.

Can you check what's in front of that token endpoint, and from inside the container (docker exec + curl) fetch the issuer's .well-known/openid-configuration to see what token_endpoint_auth_methods_supported lists?

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[puhtahtoe]

@dosu Authentik is behind an instance of Caddy but with nothing more than the basic reverse_proxy directive.

Oddly, executing curl on the Issuer address from within the Homepage container seems to be returning an empty response. This seems very strange since the OIDC flow shouldn't be able to get as far as it is without information from the Issure address.

I did have to install curl in the container since it's not by default, I don't know if that would make any difference.

Viewing the contents of the Issuer URL through other means does show token_endpoint_auth_methods_supported values of client_secret_post and client_secret_basic

Another thing possibly worth pointing out is that Homepage and Authentik are not behind the same domain. This hasn't mattered with any other OIDC client connecting to Authentik though.

[dosubot[bot]]

That empty curl response is the most interesting clue here. An empty body — rather than a TLS error or connection refused, which curl would report explicitly — suggests the response is getting swallowed somewhere on the path between Authentik and Homepage. A bare reverse_proxy directive in Caddy doesn't add anything unusual, but it's still one more hop where a truncated or hung response could occur.

Since Authentik advertises both client_secret_basic and client_secret_post in token_endpoint_auth_methods_supported, the auth-method-mismatch theory is out — it accepts either, so that isn't what's failing. That points back at the network path.

Could you rerun the curl with -v so we can see whether it completes the TLS handshake and returns a 0-byte 200, or hangs/times out? And try it against the full .../.well-known/openid-configuration path rather than the bare issuer URL — that's the URL NextAuth actually fetches for discovery and token exchange [1], so if that one is empty or hanging from inside the container, we've probably found the real break.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[puhtahtoe]

@dosu Running curl on the well-known endpoints URL works.

Running it on the Issuer URL does not.

If I open the Issuer URL in a browser it redirects to the well-known endpoints address. That redirect might be the explanation for curl returning empty on the Issuer URL.

I tried using the well-known endpoints URL in place of the Issuer address in the Homepage configuration and it still does not work.