[GH-ISSUE #6652] Refresh user name/email from the ID-token claims on login (parity with JWT group sync) #12235

Open
opened 2026-08-05 01:32:42 -04:00 by saavagebueno · 1 comment
Owner

Originally created by @tnucera on GitHub (Jul 2, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/6652

⚠️ This is not a directory-sync or SCIM request.
It does not require enabling the server-side IdP directory manager (IdpManagerConfig), and it does not need the paid Cloud/SCIM sync. It only re-reads the name and email claims that are already present in the login ID-token — exactly like the existing JWT group sync (JWTGroupsClaimName) already does for groups. No extra IdP API call, no background job, no license.

Observation

NetBird already persists name / email into the local user record at JIT creation (addNewUserToDomainAccounttypes.NewRegularUser(userId, email, name)SaveUser), sourced from the token claims. But on subsequent logins, GetUserFromUserAuth only updates last_login — it never refreshes name / email from the ID-token claims (confirmed in v0.73.2).

Consequences

  • Users created by an older version (before name/email were persisted at JIT) keep empty name / email forever: there is no login-time backfill, and the API does not allow editing those fields for IdP-managed users.
  • Anyone running IdpManagerConfig.ManagerType: "none" (a common workaround to stop the directory refresh from resetting is_blocked / renaming users to their IdP ID) then sees blank name/email, since display falls back to the stored (empty) fields.

Proposal

On login, refresh the stored name / email from the ID-token claims — mirroring the existing JWT group sync (JWTGroupsClaimName). The data is already in the token and already persisted at creation; this just keeps it consistent over time.

  • #2073 (broader "OIDC-compatible sync"; this is a narrow, JWT/login-only subset of it).
Originally created by @tnucera on GitHub (Jul 2, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/6652 > ⚠️ This is **not** a directory-sync or SCIM request. > It does **not** require enabling the server-side IdP directory manager (`IdpManagerConfig`), and it does **not** need the paid Cloud/SCIM sync. It only re-reads the `name` and `email` claims that are **already present in the login ID-token** — exactly like the existing JWT **group** sync (`JWTGroupsClaimName`) already does for groups. No extra IdP API call, no background job, no license. ### Observation NetBird already persists `name` / `email` into the local user record **at JIT creation** (`addNewUserToDomainAccount` → `types.NewRegularUser(userId, email, name)` → `SaveUser`), sourced from the token claims. But on **subsequent logins**, `GetUserFromUserAuth` only updates `last_login` — it never refreshes `name` / `email` from the ID-token claims (confirmed in `v0.73.2`). ### Consequences - Users created by an older version (before name/email were persisted at JIT) keep **empty** `name` / `email` forever: there is no login-time backfill, and the API does not allow editing those fields for IdP-managed users. - Anyone running `IdpManagerConfig.ManagerType: "none"` (a common workaround to stop the directory refresh from resetting `is_blocked` / renaming users to their IdP ID) then sees blank name/email, since display falls back to the stored (empty) fields. ### Proposal On login, refresh the stored `name` / `email` from the ID-token claims — mirroring the existing JWT **group** sync (`JWTGroupsClaimName`). The data is already in the token and already persisted at creation; this just keeps it consistent over time. ### Related - #2073 (broader "OIDC-compatible sync"; this is a narrow, JWT/login-only subset of it).
Author
Owner

@linear-code[bot] commented on GitHub (Jul 2, 2026):

NET-1352

<!-- gh-comment-id:4866435269 --> @linear-code[bot] commented on GitHub (Jul 2, 2026): <!-- linear-linkback --> <p><a href="https://linear.app/netbird/issue/NET-1352">NET-1352</a></p>
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#12235