feat(SSO): separate External ID from Username mapping - #6295

Walkthrough

The change adds an optional username field to identity-provider mappings. OAuth2 reads the configured username claim and falls back to the identifier when empty. API and store conversions preserve the mapping. SSO account creation validates the mapped username. The web dialog and mapping summary expose the field. Tests cover separate username and identifier claims and SSO account creation.

Suggested reviewers: boojack, johnnyjoygh

Merge Risk: 🔵 Low · up to b78ad

This change adds a separately configurable SSO username claim while retaining external-ID fallback for existing configurations. The feature path is covered across configuration, persistence, and user creation; adding the exported field documentation remains before merge.

• Fix all pre-merge checks with AI

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

Greptile Summary

The PR separates the stable OAuth external identity from the optional claim used to suggest a local username.

• Adds username to OAuth field mappings across the API, store schema, generated clients, and settings UI.
• Maps the configured username claim with an external-ID fallback for existing configurations.
• Keeps account lookup and linking keyed by provider and external ID while using the username only during first-account provisioning.
• Adds unit and integration coverage for separate external-ID and username mappings.

Confidence Score: 5/5

The PR appears safe to merge with no concrete correctness or security failures identified.

The new mapping is propagated across protobuf, generated, API, persistence, OAuth, provisioning, and UI boundaries; backward compatibility is preserved by falling back to the external identifier, while account linkage remains keyed by the stable provider identity.

sequenceDiagram
    participant P as OAuth Provider
    participant O as OAuth Adapter
    participant A as Auth Service
    participant D as Store
    P-->>O: external ID and optional username claim
    O->>O: Map external ID
    O->>O: Map username or fall back to external ID
    O->>A: UserInfo(external ID, username)
    A->>D: Resolve link by provider and external ID
    alt Existing identity link
        D-->>A: Existing local user
    else First sign-in
        A->>A: Validate username suggestion
        A->>D: Create user and external identity atomically
    end

_{Reviews (1): Last reviewed commit: "feat: add separate SSO username mapping" | Re-trigger Greptile}