Phase 4c: Intercept non-SSO logins for enforced domains

[GregorShear]

• Add enforce_sso boolean column to tenants.
• GoTrue customize_access_token hook (check_sso_requirement) blocks social login for users with email covered by tenant's SSO domains
• The hook checks auth.users.is_sso_user — SSO users always pass through (important for token refresh).
• Blocked logins receive a 403 error with message: 'sso_required:<domain>' — the frontend parses the domain and calls supabase.auth.signInWithSSO({ domain }) to redirect the user to their IdP.

Users whose email domain does NOT match an enforcing tenant's SSO domain (e.g., contractors with @gmail.com) are not blocked by the hook. Their grants on enforcing tenants are handled by grant filtering in 4d instead.

Activated by enforce_sso = true. Tenants configure SSO first, then communicate the transition to their users. enforce_sso is flipped on a hard cutoff date.

Verify:

• Social user with matching email domain on enforcing tenant → blocked with sso_required:<domain>
• Social user with matching domain, enforce_sso = false → not blocked
• Social user with non-matching domain (e.g. @gmail.com) → not blocked (grants handled by 4d)
• SSO user (is_sso_user = true) with matching domain → not blocked (token refresh works)
• Blocked user redirected via signInWithSSO({ domain }) → authenticates via IdP → grant migration trigger fires
• Malformed hook input → exception caught, login not blocked, warning logged

[GregorShear]

Looking for input here - should we block or pass users on exception? do we favor breaking login, or adding a security hole?

either way i'll need help setting up an alert for that warning.

[GregorShear]

100% claude generated script for setting up mocksaml in a dev environment. it works on my machine... :)

[GregorShear]

will probably remove this skill in favor of the start-with-saml.sh script below

[GregorShear]

for dev environment - will have to configure this via the supabase dashboard in production

[GregorShear]

I've removed the exception handler so exceptions will bubble up to the caller - is this the right approach? is there any specific monitoring we need to set up or are all exceptions like readily visible? (where would i look for these anyway?)