Hi all!
First time poster. Developing my first app that uses Supabase. About 6.5 months in :)
When a user has enrolled a TOTP factor, Supabase currently still accepts aal1 JWTs for API queries. That essentially makes MFA very easy to bypass by any bad actor that has a user's password, unless you take certain cumbersome precautions. Enforcement of aal2 is only possible by manually adding (auth.jwt() ->> 'aal') = 'aal2' to every RLS policy — which is error-prone, easy to miss on new tables, and requires developers to remember to do this consistently (you could also add it as conditional so it only requires aal2 if the user has opted into TOTP).
Requested behavior:
An option (per-project or per-user) that causes PostgREST/the API gateway to automatically reject any request bearing an aal1 token if the authenticated user has one or more verified MFA factors enrolled. This would mirror how Azure AD Conditional Access works: MFA enrollment triggers automatic token-level enforcement, not just UI-layer enforcement.
Proposed implementation surface:
"Require AAL2 for MFA-enrolled users" (boolean toggle)Why this matters:
Without this, an attacker who obtains a user's password can call signInWithPassword() directly, receive a valid aal1 JWT, and query the PostgREST API with the aal1 JWT to exfiltrate data — bypassing MFA entirely. MFA provides UI-layer protection only, not data-layer protection. This is a meaningful distinction for apps storing sensitive user data.
Workaround today:
Add AND (auth.jwt() ->> 'aal') = 'aal2' to every RLS SELECT/INSERT/UPDATE/DELETE policy. This works but is fragile — any new table or missed policy is a silent vulnerability.
Could we get this feature implemented? I would LOVE this. It would make every supabase project able to be much more resilient to sophisticated penetration attacks.
The user requests a feature to automatically enforce AAL2 for MFA-enrolled users at the API gateway level. Currently, Supabase accepts aal1 JWTs even when a user has enrolled a TOTP factor, which can be bypassed by attackers with a user's password. The user suggests a project-level or user-level setting to reject aal1 tokens for MFA-enrolled users, enhancing security by preventing data exfiltration through API queries.