fix(auth): log the real cause of OIDC/OAuth user-info failures#10679
Merged
Conversation
The OAuth callback discarded the error returned by user-info resolution before sending the generic 500, so real failures were completely opaque in the logs: ID-token verification errors (e.g. issuer/audience mismatch behind a reverse proxy), a missing id_token, claim-parse errors, or a rejecting GitHub userinfo endpoint all collapsed into "failed to fetch user info" with nothing logged. Log the wrapped cause with xlog.Error (provider + error), matching the code-exchange step just above it. The client-facing message is unchanged, so no internal detail leaks to the browser. Refs #10677 Signed-off-by: Ettore Di Giacinto <mudler@localai.io> Assisted-by: Claude:claude-opus-4-8 [Claude Code]
mudler
added a commit
that referenced
this pull request
Jul 8, 2026
…10736) The OIDC verifier was built with a bare oidc.Config{ClientID: ...}, so go-oidc applied its default of accepting RS256-signed ID tokens only. An identity provider configured with an EC signing key (e.g. Authentik) issues ES256-signed tokens, and the callback failed verification with: failed to verify ID token: oidc: malformed jwt: unexpected signature algorithm "HS256"; expected ["RS256"] surfacing to the user as HTTP 500 "failed to fetch user info" (#10677; the underlying cause became visible after the logging fix in #10679). Set SupportedSigningAlgs to the standard asymmetric algorithms (RS256/384/512, ES256/384/512, PS256/384/512, EdDSA). All are verified against the provider's published JWKS. HS256 is intentionally excluded: it is symmetric and would validate against the client secret, a different and security-sensitive trust model. Tested with a functional spec that signs an ES256 ID token and confirms it verifies with the configured algorithms and is rejected under go-oidc's RS256-only default (using oidc.StaticKeySet, no network). Closes #10677 Assisted-by: Claude:claude-opus-4-8 [Claude Code] Signed-off-by: Ettore Di Giacinto <mudler@localai.io> Co-authored-by: Ettore Di Giacinto <mudler@localai.io>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The OAuth callback discarded the error returned by user-info resolution before sending the generic
500 {"error":"failed to fetch user info"}, so real failures were completely opaque in the logs. This adds anxlog.Errorat the swallow site (matching the code-exchange step just above it), surfacing the wrapped cause: ID-token verification errors (e.g. issuer/audience mismatch behind a reverse proxy), a missingid_token, claim-parse errors, or a rejecting GitHub/userresponse.The client-facing message is unchanged, so no internal detail leaks to the browser; details go to server logs only.
Why
Refs #10677. An Authentik user hit
HTTP 500 {"error":"failed to fetch user info"}at/api/auth/oidc/callbackwith nothing logged explaining the cause. This is the observability half of that report: it makes the failure self-diagnosable.The suspected root cause (the OIDC path reads claims only from the ID token and never calls
/userinfo, which Authentik commonly relies on) is intentionally not addressed here. It touches the security-sensitive verification path, so it's held until an affected user confirms, from these new logs, that ID-token-only extraction is the actual failure - rather than an issuer/proxy misconfiguration.Testing
make lint(new-from-merge-base): 0 issuesmake test-coverage-check: allpkg/...andcore/...suites pass, including thecore/httpe2e suiteAssisted-by: Claude:claude-opus-4-8 [Claude Code]