From d8196ce4999d26f2efd744922c976678b7093b6e Mon Sep 17 00:00:00 2001 From: Frank Date: Tue, 20 Oct 2026 20:41:57 -0700 Subject: [PATCH] docs: Grafana reads claims from userinfo, not USE_ID_TOKEN The login lands once authentik emits the email claim (the IdP fix); Grafana needs no USE_ID_TOKEN toggle, and dropping it also avoids a *_TOKEN false-positive in the literal-secret seam. Correct the two SSO notes accordingly. --- .../Infrastructure/Authentik Outpost Reference.md | 12 ++++++------ serverAppConfigs-docs/Infrastructure/Grafana.md | 10 +++++----- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/serverAppConfigs-docs/Infrastructure/Authentik Outpost Reference.md b/serverAppConfigs-docs/Infrastructure/Authentik Outpost Reference.md index 028d4e6..596ac89 100644 --- a/serverAppConfigs-docs/Infrastructure/Authentik Outpost Reference.md +++ b/serverAppConfigs-docs/Infrastructure/Authentik Outpost Reference.md @@ -119,13 +119,13 @@ implementation diverges from upstream in ways that bit us; all verified live: `return {"email": user.email, "email_verified": True}`. With no email, Grafana v13 falls back to GET `/emails`; authentik 404s it → "Login failed: InternalError". -- **Claims ride in the id_token.** `include_claims_in_id_token` is on for this - provider and Grafana reads identity from it (`USE_ID_TOKEN=true`). +- **Grafana reads identity from the standard userinfo endpoint** (`API_URL` with + no `?api=1`); no `USE_ID_TOKEN` is needed once the `email` claim exists. - **Net (2026-10-20):** the evaluator is fine; email/profile claims reach RP - clients. Both IdP fixes are idempotent in `scripts/authentik-grafana-sso-fix.sh` - (re-run after an ak-shell re-creation of the provider or a blueprint import, - which revert them). Grafana's half + the verified outcome (Viewer, - `login = `, email present) are in [[Grafana]]. + clients. Both IdP fixes are idempotent in + `scripts/authentik-grafana-sso-fix.sh` (re-run after an ak-shell re-creation of + the provider or a blueprint import, which revert them). Grafana's half plus the + verified outcome (Viewer, `login = `, email present) are in [[Grafana]]. ## LDAP provider objects (provisioned via `ak shell` ORM) diff --git a/serverAppConfigs-docs/Infrastructure/Grafana.md b/serverAppConfigs-docs/Infrastructure/Grafana.md index 6325202..5d1f028 100644 --- a/serverAppConfigs-docs/Infrastructure/Grafana.md +++ b/serverAppConfigs-docs/Infrastructure/Grafana.md @@ -75,11 +75,11 @@ Grafana responds on `/api/health` with 200 and `"database":"ok"`; measured 2026- an ak-shell re-creation of the provider or a blueprint import, both of which revert it silently). The Grafana half is the unit's own env (`grafana.container`): `SCOPES="openid email profile"` (a GitLab-style `user:email` scope crashes the - authorize view), `USE_ID_TOKEN=true` + no `?api=1` (Grafana v13 otherwise GETs - `/emails`, which authentik 404s and the login dies with "Login failed: - InternalError"), attribute paths `email`/`sub`/`preferred_username`, and - `ALLOW_SIGN_UP=true` — safe because the guard fronts every request, so the - callback is unreachable to unauthenticated traffic. + authorize view), the standard userinfo `API_URL` with **no `?api=1`**, the + attribute paths `email`/`sub`/`preferred_username`, and `ALLOW_SIGN_UP=true` + (safe: the guard fronts the callback). Grafana v13 only GETs `/emails` + when the token carries no `email` claim — so it is the email claim itself (an + IdP fix, above) that makes the login land, not any Grafana toggle. - **What a new login becomes:** a Viewer in org 1 (`ALLOW_ASSIGN_ORG=true`, `ORG_ID=1`, no role-attribute mapping), with `login = ` but the real `email`. The local admin account stays the only Admin. The landing that the