supabase / auth / 28178220953

71%

push

github

feat(custom-oauth): add per-provider custom_claims_allowlist (#2576)

## What kind of change does this PR introduce?

Feature

 ## What

Adds a per-provider `custom_claims_allowlist` to custom OAuth/OIDC
providers: a flat list of raw IdP claim keys that get copied verbatim
into `custom_claims` on the user's `identity_data` /
`raw_user_meta_data`.

  ```
  PATCH /admin/custom-providers/custom:acme
  { "custom_claims_allowlist": ["groups", "org_id", "mail", "sn"] }

Result, queryable in a before insert on auth.users trigger (and stored
in the auth.identities table as well for future queries):
"custom_claims": { "groups": [...], "org_id": "...", "mail": "...",
"sn": "..." }
```

## Why

Admins integrating non-standard IdPs need to read provider-specific claims (e.g. groups, mail, nlEduPersonProfileId) that don't map to standard fields. This is the allowlist design rather than a denylist (previous implementation: https://github.com/supabase/auth/pull/2520):

- No Azure "re-add stripped claims" risk: we only copy keys explicitly named, so a parser that strips a claim stays authoritative.
- No reflection, no exhaustive exclusion set to maintain, no ordering hazard with ParseIDToken.

Design decisions
- Default = empty -> capture nothing. Opt-in only.
- text[] column (slices.String), matching `scopes` / `acceptable_client_ids`.
- Distinct from attribute_mapping: the allowlist copies raw source keys into the opaque custom_claims bucket; attribute_mapping remaps typed fields. No privilege-escalation surface, so no blocked-target guard (only a non-empty-entry check).
- Capture runs before applyAttributeMapping at all sources (OAuth userinfo, OIDC userinfo) via one captureAllowedClaims helper.

77 of 89 new or added lines in 4 files covered. (86.52%)

17930 of 25152 relevant lines covered (71.29%)

665.04 hits per line