ui: Display the authenticated user by configured userIdClaim

[marcofranssen]

Summary

• Adds KAGENT_USER_ID_CLAIM environment variable to the UI pod, sourced from controller.auth.userIdClaim in values.yaml
• Exposes a getUserIdClaim() server action that reads KAGENT_USER_ID_CLAIM (defaults to "sub")
• Extends AuthContext to fetch the configured claim name alongside the JWT and expose it as userIdClaim
• Updates AppInitializer to sync the authenticated user's identity into userStore using the configured claim (e.g. email, preferred_username, sub) so the correct value is displayed in the UI

Motivation

When deploying with auth.mode: trusted-proxy and controller.auth.userIdClaim: email, the UI was still showing the raw sub value (typically an opaque ID) instead of the user's email. This was because userStore was seeded from localStorage and never synchronized with the authenticated JWT claims.

How it works

values.yaml
  controller.auth.userIdClaim: email
        │
        ▼
ui-deployment.yaml
  KAGENT_USER_ID_CLAIM=email
        │
        ▼
auth.ts: getUserIdClaim()   +   getCurrentUser() (JWT decode)
        │                               │
        └───────────┬───────────────────┘
                    ▼
           AuthContext: { user, userIdClaim }
                    │
                    ▼
          AppInitializer: setUserId(user[userIdClaim])
                    │
                    ▼
             userStore (displayed in UI)

Test plan

• Deploy with controller.auth.userIdClaim: email and auth.mode: trusted-proxy — UI should display the email from the JWT
• Deploy with controller.auth.userIdClaim: preferred_username — UI should display the preferred username
• Deploy without setting userIdClaim (default) — UI should fall back to sub
• Deploy in unsecure mode (no JWT) — UI should fall back to the default admin@kagent.dev

[Copilot]

Pull request overview

Surfaces the authenticated user's identifier in the UI based on the configurable userIdClaim (instead of hardcoding sub), so deployments whose OIDC providers use a different claim populate the user store with the correct identity. The Helm chart now propagates controller.auth.userIdClaim into the UI deployment as KAGENT_USER_ID_CLAIM, which the new server-side helper reads.

Changes:

• Add getUserIdClaim server helper and expose userIdClaim through AuthContext.
• In AppInitializer, read the identity from the JWT claim and seed useUserStore.setUserId.
• Inject KAGENT_USER_ID_CLAIM env var into the UI Deployment from the controller auth values.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
ui/src/app/actions/auth.ts	New getUserIdClaim returning the env-configured claim (defaults to sub).
ui/src/contexts/AuthContext.tsx	Fetches the claim in parallel with the user and exposes it via context.
ui/src/components/AppInitializer.tsx	Uses the claim to extract the user identity and write it into useUserStore.
helm/kagent/templates/ui-deployment.yaml	Passes controller.auth.userIdClaim into the UI pod as KAGENT_USER_ID_CLAIM.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[EItanya]

We already have the current user handler. Should we instead expand that to include more information? I favor backend solutions usually