fix: set authMethod to OIDC for SCIM-provisioned users

[TerrifiedBug]

Summary

• SCIM-provisioned users were created with authMethod defaulting to LOCAL (schema default), which blocked OIDC login with "local account exists" error
• Sets authMethod: "OIDC" in scimCreateUser so SCIM-provisioned users can authenticate via SSO
• This also unblocks OIDC group sync — team assignment happens on first OIDC login via the groups claim, which requires successful sign-in

Test plan

• Delete an SSO user from the database
• Trigger SCIM sync from IdP
• Verify user is recreated with authMethod: OIDC
• Verify OIDC login succeeds (no "local account" error)
• Verify team membership is assigned on login via OIDC group mappings

[greptile-apps]

Greptile Summary

This PR fixes a correctness bug where SCIM-provisioned users were created with authMethod: "LOCAL" (the Prisma schema default), causing their subsequent OIDC login attempts to be rejected with a "local account exists" error. The one-line fix adds authMethod: "OIDC" to the prisma.user.create call in scimCreateUser, aligning SCIM provisioning with the intended SSO-only authentication model and unblocking OIDC group sync on first login.

Key observations:

• The core fix is correct and minimal — newly SCIM-provisioned users will now have authMethod: "OIDC" and can authenticate via SSO immediately.
• Adoption path gap: The adoption update (lines 120–126), which handles users that already exist when a SCIM create arrives, only updates scimExternalId and does not update authMethod. This means users who were SCIM-provisioned before this fix (with authMethod: "LOCAL" from the old default) remain blocked even after an IdP re-sync triggers the adoption branch. The OIDC login blocking logic in auth.ts (lines 229–241) explicitly rejects OIDC sign-in for authMethod: "LOCAL" accounts, confirming that this scenario is a real blocker. Adding authMethod: "OIDC" to the adoption update would self-heal those accounts without a separate data migration.
• No security regression is introduced: the OIDC-vs-LOCAL blocking logic in auth.ts is unchanged, and the randomly generated temp password for SCIM users remains inaccessible for local login.

Confidence Score: 3/5

• Safe to merge for new provisioning, but existing SCIM users with authMethod: "LOCAL" remain broken without an adoption path fix or manual migration.
• The one-line change is correct and doesn't introduce regressions. However, the adoption path gap means the fix is incomplete for any deployment that already has SCIM-provisioned users. Those users still can't log in via OIDC after a re-sync, which is the stated goal of the PR. The issue is real and verified: the adoption condition (line 110) allows users with pre-existing scimExternalId through regardless of authMethod, and auth.ts explicitly blocks OIDC login for LOCAL accounts (lines 229–241).
• src/server/services/scim.ts — specifically the adoption update block (lines 120–126) which should also set authMethod: "OIDC"

Comments Outside Diff (1)

1. src/server/services/scim.ts, line 120-126 (link)

   Adoption path doesn't repair authMethod for existing SCIM users

   The fix correctly sets authMethod: "OIDC" for newly created SCIM users, but the adoption path (reached when a user already exists in the DB) only updates scimExternalId. This means any user who was SCIM-provisioned before this fix (and therefore has authMethod: "LOCAL" from the old schema default) will still be blocked from OIDC login even after the IdP sends a subsequent SCIM create/re-sync.

   The adoption condition at line 110 allows users with a pre-existing scimExternalId (regardless of authMethod) through to this update block, so the scenario is reachable in production for any tenant that already had SCIM provisioning enabled.

   Without this, the complete fix for existing environments requires either a data migration or manually deleting and re-syncing every affected user — an error-prone manual step that should be avoided when the adoption path already has the right context to perform the repair automatically.

_{Last reviewed commit: 072964e}