jhodgkin
9b5051d3ac
fix: OIDC_ISSUER_URL used Authentik's LAN IP (192.168.1.208:9443). Authentik's discovery doc echoes back whichever host you query it through, so that LAN IP got baked into authorization_endpoint -- the URL the *browser* gets redirected to. Anyone off the LAN got sent to an address they couldn't reach. Authentik was already publicly exposed at auth.jerodrigged.com (pre-existing NPM proxy host); switched to that, which also has a real cert so OIDC_ALLOW_INSECURE_TLS could go back to false. Reported as "signed in via Authentik, redirected to the local IP, failed." fix: frontend's request() helper always sent Content-Type: application/json, even for logout's bodyless POST. Fastify's default JSON parser rejects an empty body under that content-type (400) -- sign-out silently failed to log the user out. curl-based testing missed this because curl doesn't set that header without -d. Caught immediately by the new Playwright local-login test. e2e/: Playwright suite for local auth and OIDC login. OIDC test uses a dedicated Authentik test user (blueprint-provisioned, never a real personal login) so the whole flow can run unattended and repeatedly. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
62 lines
3.5 KiB
Markdown
62 lines
3.5 KiB
Markdown
# Authentik OIDC setup
|
|
|
|
Local auth (bcrypt + session, the saved Vaultwarden password) is always available.
|
|
When `OIDC_ENABLED=true`, the login page additionally shows a "Sign in with Authentik"
|
|
button — this is additive, not a replacement, so the existing admin login keeps working.
|
|
|
|
## How the Authentik side was provisioned
|
|
|
|
No API token or admin credentials were needed. Authentik supports **blueprints** —
|
|
declarative YAML files it applies automatically — so the OAuth2 Provider + Application
|
|
were created via `/opt/authentik/blueprints-local/homelab-monitor-oidc.yaml` on CT121,
|
|
picked up by the `worker` container on startup. This is purely additive: it doesn't
|
|
touch any existing user, group, or admin credential.
|
|
|
|
- Blueprint volume mount added to `/opt/authentik/docker-compose.yml` (backed up as
|
|
`docker-compose.yml.bak-homelab-monitor` before editing) for both `server` and `worker`.
|
|
- Provider: confidential client, `default-provider-authorization-implicit-consent` flow
|
|
(auto-approve — reasonable for a single-user personal dashboard), signed with
|
|
Authentik's existing self-signed cert.
|
|
- Redirect URIs (both registered): `https://monitor.jerodrigged.com/api/auth/oidc/callback` (primary,
|
|
set in `.env`) and `http://192.168.1.103:8090/api/auth/oidc/callback` (LAN fallback, works if the
|
|
tunnel/DNS is down).
|
|
- Application slug: `homelab-monitor`.
|
|
|
|
To change anything (redirect URI, flow, scopes), edit the blueprint file on CT121 and
|
|
either wait for Authentik's file-watcher or `docker restart authentik-worker-1` — it
|
|
re-applies on any change to the file.
|
|
|
|
## Bug: LAN-IP issuer sent browsers somewhere they couldn't reach
|
|
|
|
First deploy used `OIDC_ISSUER_URL=https://192.168.1.208:9443/application/o/homelab-monitor/`
|
|
(Authentik's LAN IP) for discovery. Authentik's discovery document **echoes back whichever
|
|
host you queried it through** — so `authorization_endpoint` came back as that same LAN IP.
|
|
That value gets handed straight to the *browser* as a redirect target. Anyone off the LAN
|
|
(or just not on wifi) got redirected to an address they couldn't reach at all — reported as
|
|
"signed in via Authentik, got sent to the local IP, and it failed."
|
|
|
|
Fix: Authentik was **already** publicly exposed at `https://auth.jerodrigged.com` (NPM proxy
|
|
host id 9, predates this project) with a real Let's Encrypt cert — just wasn't the one used
|
|
for `OIDC_ISSUER_URL`. Switched to it; `OIDC_ALLOW_INSECURE_TLS` could then go back to `false`
|
|
too, since it's not a self-signed cert. **Always use the public issuer URL for anything a
|
|
browser is ever redirected through**, even though the app's own server-to-server calls
|
|
(token exchange, userinfo, jwks — all made directly by the Node process, never by a browser)
|
|
would have worked fine against the LAN IP too.
|
|
|
|
## API-side implementation
|
|
|
|
`apps/api/src/auth/oidc.ts` uses `openid-client` v6 with PKCE + state, with an optional
|
|
insecure-TLS fetch override (`OIDC_ALLOW_INSECURE_TLS`) for the rare case the issuer is
|
|
LAN-only with a self-signed cert — not needed now that the issuer is the public URL, but
|
|
kept since Authentik's LAN address still works as a fallback if `auth.jerodrigged.com` is
|
|
ever unreachable. Routes in `apps/api/src/routes/oidc.ts`:
|
|
|
|
- `GET /api/auth/oidc/login` — redirects to Authentik's authorization endpoint
|
|
- `GET /api/auth/oidc/callback` — exchanges the code, sets `req.session.username` from
|
|
the `preferred_username` (falls back to `email`, then `sub`) ID token claim
|
|
|
|
## Credentials
|
|
|
|
`OIDC_CLIENT_ID`/`OIDC_CLIENT_SECRET` are in CT122's `.env` and saved in Vaultwarden
|
|
alongside the local admin login.
|