feat(scim): store a per-provider SCIM token

[xlgmokha]

What kind of change does this PR introduce?

Feature. Adds sso_providers.scim_token_hash, a SHA-256 hex digest of the provider's SCIM token, with a partial unique index over the non-null values.

https://linear.app/supabase/issue/AUTH-1368/scim-users-get-by-id)

What is the current behavior?

The /scim/v2 router ships dark behind GOTRUE_EXPERIMENTAL_SCIM_ENABLED and serves the three discovery endpoints, but it has no authentication at all.

There is no way to associate a SCIM request with an SSO provider: sso_providers has no SCIM columns.

ServiceProviderConfig already advertises oauthbearertoken as its primary authentication scheme, with nothing behind it.

What is the new behavior?

sso_providers gains scim_token_hash, holding the SHA-256 hex digest of the provider's SCIM token, plus a partial unique index over the non-null values.
The plaintext token is never stored. Resolution is a single indexed equality on the digest of a secret, so there is no plaintext comparison and no timing-sensitive path.

Additional context

[depthfirst-app]

⚪ Severity: LOW

SCIMTokenHash is a bare, unsalted SHA-256 digest, while UpdateSCIMToken accepts arbitrary token strings without an entropy requirement. A database reader can test candidate low-entropy or provider-chosen tokens offline, recover a bearer token, and use it against the SCIM provider lookup.
Helpful? Add 👍 / 👎

💡 Fix Suggestion

Suggestion: There are two complementary mitigations needed:

1. Enforce minimum token entropy: Change UpdateSCIMToken to return an error and reject tokens shorter than 32 bytes (e.g., if len(token) < 32 { return errors.New("SCIM token must be at least 32 characters") }). This prevents low-entropy tokens from being stored and makes offline dictionary attacks impractical. Update all callers accordingly.

2. Replace unsalted SHA-256 with bcrypt: Since golang.org/x/crypto is already a dependency, replace toSHA256 with bcrypt.GenerateFromPassword([]byte(token), bcrypt.DefaultCost) so each stored hash gets a unique, random salt. This makes offline brute-force exponentially harder. Note that bcrypt is non-deterministic, so the equality-based lookup in FindSSOProviderBySCIMToken (WHERE scim_token_hash = ?) must be replaced with a fetch-then-compare pattern: load all providers with a non-null scim_token_hash (SCIM provider counts are small) and use bcrypt.CompareHashAndPassword to find a match. Alternatively, keep a fast SHA-256 lookup index but store a bcrypt hash as the authoritative credential field and verify using bcrypt after the indexed lookup.