fix(sso): prefer UserInfo endpoint over ID token and map sub claim correctly#8276
fix(sso): prefer UserInfo endpoint over ID token and map sub claim correctly#8276
Conversation
The UserInfo endpoint fallback path was assigning the raw response directly to userInfo and then checking for userInfo.id, which doesn't exist in standard OIDC responses. Per the OIDC spec (Section 5.1), providers use the sub claim as the subject identifier. Apply the same mapping logic (sub→id, picture→image, email_verified→emailVerified, extraFields) to the UserInfo endpoint path that already existed for the ID token path. Fixes #8269
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
@better-auth/api-key
better-auth
auth
@better-auth/core
@better-auth/drizzle-adapter
@better-auth/electron
@better-auth/expo
@better-auth/i18n
@better-auth/kysely-adapter
@better-auth/memory-adapter
@better-auth/mongo-adapter
@better-auth/oauth-provider
@better-auth/passkey
@better-auth/prisma-adapter
@better-auth/redis-storage
@better-auth/scim
@better-auth/sso
@better-auth/stripe
@better-auth/telemetry
@better-auth/test-utils
commit: |
There was a problem hiding this comment.
Pull request overview
This PR fixes an OIDC compliance bug in the SSO module where the UserInfo endpoint fallback path was looking for an id claim (non-standard) instead of sub (OIDC spec Section 5.1 standard). The fix applies the same claim mapping logic that already existed for the ID token path to the UserInfo endpoint path as well, enabling correct sign-in with providers like Tinyauth that don't include user claims in the ID token.
Changes:
- Applied full claim mapping logic (
sub→id,picture→image,email_verified→emailVerified,extraFields) to the UserInfo endpoint fallback path, consistent with the existing ID token path. - Changed the
betterFetchgeneric type from an explicit fixed-shape interface toRecord<string, unknown>to accurately reflect raw OIDC UserInfo responses.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
@himself65 maybe you should also prioritize the user-info endpoint instead of the ID token since it tends to be more reliable. |
Regression test for #8269: verifies that SSO login succeeds when the OIDC provider returns no ID token (access-token-only flow) and the UserInfo endpoint returns the standard sub claim instead of id.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
When a userInfoEndpoint is configured, use it as the primary source of user claims rather than falling back to it only when there is no ID token. The UserInfo endpoint is always up-to-date and is the authoritative OIDC source for user attributes. Fallback order is now: UserInfo endpoint → ID token → error.
…rrectly (#8276) Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
…rrectly (#8276) Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
…rrectly (better-auth#8276) Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
…rrectly (better-auth#8276) Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Summary
userInfo.id, but standard OIDC providers returnsub(notid) as the subject identifier per OIDC spec Section 5.1sub→id,picture→image,email_verified→emailVerified,extraFields) to the UserInfo endpoint path that already existed for the ID token pathbetterFetchgeneric type toRecord<string, unknown>to accurately reflect raw OIDC UserInfo responsesFixes #8269
Test plan
pnpm vitest packages/sso/src --run)