fix(web-arm): fix Immich OIDC token auth, offer both login methods #182

Merged

dominik.polakovics merged 1 commit from fix/web-arm-immich-oidc-login into main

2026-06-26 16:39:53 +02:00

dominik.polakovics commented

2026-06-26 16:38:16 +02:00

Owner

Why

After deploying #181, signing in via Authelia failed with "Failed to finish oauth". The immich-server log showed the real cause at the token-exchange step:

error: 'invalid_client',
error_description: "... 'token_endpoint_auth_method' method 'client_secret_post',
however the OAuth 2.0 client registration does not allow this method."

Immich's OAuth client (oauth4webapi) authenticates to Authelia's token endpoint with client_secret_post (secret in the request body), but the immich client had no token_endpoint_auth_method set, so Authelia applied its confidential-client default of client_secret_basic and rejected the exchange. This is the documented Authelia↔Immich setting, and three existing clients here (freescout, synapse, claude-mcp-forgejo) already set it.

What

authelia.nix — set token_endpoint_auth_method = "client_secret_post" on the immich client. This is the actual fix for the login failure.
immich/default.nix — passwordLogin.enabled = true and oauth.autoLaunch = false, so the login page now shows both the password form and the "Login with Authelia" button and either can be chosen per login (password login is the admin's fallback when Authelia is unreachable).

Trade-off (documented in the module): password login is a parallel path that bypasses the group:immich authorization gate. Only admin-created accounts hold a password; OAuth-registered members have none unless they set one.

Post-deploy (manual)

The admin account was bootstrapped with an email that does not match the Authelia-asserted email. With autoRegister = true, a first OAuth login on a mismatched email creates a new, non-admin user instead of linking to the admin (Immich links OAuth→account by normalized email). So after deploy: log in via password as admin → Account Settings → set the email to your Authelia/LDAP email → then "Login with Authelia" links to the same admin account.

Relates to #178 (already merged/closed).

Verification

Pre-commit dry-build passes for web-arm.
Config schema (token_endpoint_auth_method, passwordLogin, oauth.autoLaunch) validated against the immich 2.7.5 schema; runtime confirmation is the post-deploy login test above.

## Why After deploying #181, signing in via Authelia failed with **"Failed to finish oauth"**. The immich-server log showed the real cause at the token-exchange step: ``` error: 'invalid_client', error_description: "... 'token_endpoint_auth_method' method 'client_secret_post', however the OAuth 2.0 client registration does not allow this method." ``` Immich's OAuth client (`oauth4webapi`) authenticates to Authelia's token endpoint with **`client_secret_post`** (secret in the request body), but the `immich` client had no `token_endpoint_auth_method` set, so Authelia applied its confidential-client default of `client_secret_basic` and rejected the exchange. This is the documented Authelia↔Immich setting, and three existing clients here (freescout, synapse, claude-mcp-forgejo) already set it. ## What - **`authelia.nix`** — set `token_endpoint_auth_method = "client_secret_post"` on the `immich` client. This is the actual fix for the login failure. - **`immich/default.nix`** — `passwordLogin.enabled = true` and `oauth.autoLaunch = false`, so the login page now shows **both** the password form and the "Login with Authelia" button and either can be chosen per login (password login is the admin's fallback when Authelia is unreachable). **Trade-off (documented in the module):** password login is a parallel path that bypasses the `group:immich` authorization gate. Only admin-created accounts hold a password; OAuth-registered members have none unless they set one. ## Post-deploy (manual) The admin account was bootstrapped with an email that does **not** match the Authelia-asserted email. With `autoRegister = true`, a first OAuth login on a mismatched email creates a *new, non-admin* user instead of linking to the admin (Immich links OAuth→account by normalized email). So after deploy: log in via **password** as admin → Account Settings → set the email to your Authelia/LDAP email → then "Login with Authelia" links to the same admin account. Relates to #178 (already merged/closed). ## Verification - Pre-commit dry-build passes for web-arm. - Config schema (`token_endpoint_auth_method`, `passwordLogin`, `oauth.autoLaunch`) validated against the immich 2.7.5 schema; runtime confirmation is the post-deploy login test above.

dominik.polakovics added 1 commit

2026-06-26 16:38:16 +02:00

fix(web-arm): fix Immich OIDC token auth, offer both login methods d5b5d45d21

Immich's OAuth client (oauth4webapi) authenticates to Authelia's token endpoint with client_secret_post, but the immich client defaulted to client_secret_basic and rejected it with invalid_client, surfacing as "Failed to finish oauth" in the web UI. Opt the client into client_secret_post, matching the other clients that already need it.

Also enable password login alongside OAuth and stop auto-launching the OAuth flow, so the login page presents both the password form and the Authelia button and either can be chosen per login. Password login is the admin's fallback when Authelia is unreachable.

dominik.polakovics merged commit cc103c5aa1 into main

2026-06-26 16:39:53 +02:00

dominik.polakovics deleted branch fix/web-arm-immich-oidc-login

2026-06-26 16:39:53 +02:00

dominik.polakovics referenced this pull request from a commit

2026-06-26 16:39:55 +02:00

Merge pull request 'fix(web-arm): fix Immich OIDC token auth, offer both login methods' (#182) from fix/web-arm-immich-oidc-login into main

dominik.polakovics referenced this pull request

2026-06-26 17:03:08 +02:00

web-arm: migrate existing Nextcloud photos into Immich (manual, one-time) #184