feat(custom-oauth): preserve non-standard IdP claims in identity_data

[cemalkilic]

Summary

• Custom OAuth/OIDC providers now preserve non-standard IdP claims (groups, roles, org_id, tenant_id, …) in auth.identities.identity_data and auth.users.raw_user_meta_data under the custom_claims key. Previously these were silently dropped by the typed Claims decode.
• Scoped to CustomOAuthProvider and CustomOIDCProvider. Built-in providers (Google, Apple, GitHub, Azure, …) are unchanged.
• No schema migration, existing JSONB columns already support this.

Why

• Customers flagged that userinfo claims they rely on (org IDs, tenant IDs, group / role lists from their custom OIDC IdPs) were not appearing in their Postgres auth schema. They want to use these claims transactionally, reject sign-in if a required claim is missing, and keep that data inside Supabase rather than re-fetching out-of-band. The IdP already returns the data and we already verify it during callback; we just weren't persisting it.

[fadymak]

Thanks @cemalkilic — I left a few comments 👀 My hesitation is around persisting all fields to identity data as opposed to having some allow list that can be configured per-provider which feels like the cleaner/safer approach.

[fadymak]

I believe this would cause us to re-add any claims we explicitly excluded for certain providers (e.g.: removeAzureClaimsFromCustomClaims):

auth/internal/api/provider/oidc.go

Lines 307 to 327 in be317c1

	// removeAzureClaimsFromCustomClaims contains the list of claims to be removed
	// from the CustomClaims map. See:
	// https://learn.microsoft.com/en-us/azure/active-directory/develop/id-token-claims-reference
	var removeAzureClaimsFromCustomClaims = []string{
	"aud",
	"iss",
	"iat",
	"nbf",
	"exp",
	"c_hash",
	"at_hash",
	"aio",
	"nonce",
	"rh",
	"uti",
	"jti",
	"ver",
	"sub",
	"name",
	"preferred_username",
	}

[fadymak]

My concern is that Claims doesn't capture actual standard claims (including SB-specific ones), e.g.: nbf, nonce, etc... which would end up in the custom claims and it doesn't feel like the right place, nor should they be persisted IMO

[IdrisCelik]

Thanks again @cemalkilic , I wanted to add that we were running into this problem as well, so it's great to see this addressed.

Thanks @cemalkilic — I left a few comments 👀 My hesitation is around persisting all fields to identity data as opposed to having some allow list that can be configured per-provider which feels like the cleaner/safer approach.

-- @fadymak

I understand this hesitation, we would still love to see this as is or with a allow list (or even better claims mapping like with saml attribute mapping) that can be set by us by for example using the createProvider method, this because we are using a standardized IdP proxy for our market and they along with many others use non standard claims like mail, sn, nlEduPersonProfileId which we need in our before insert on auth.users trigger.

Hitting the userinfo endpoint ourselves with the token would mean we lose transactional integrity which is a big reason we wanted to go with Supabase auth.