---
title: "Multi-factor Authentication via Row Level Security Enforcement"
description: "Supabase announces the release of multi-factor authentication (MFA) for everyone and describes dashboard Single Sign-On (SSO) as preparation for a future SAML release; SSO is available on Enterprise plans by contacting the company. The implementation starts with Time-Based One-Time Passwords (TOTP), where an authenticator generates a short-lived code from a shared secret and the current time, exchanged through a QR code or entered manually. Enrollment uses /enroll, /challenge, and /verify, while subsequent sign-ins require a challenge and verification before a JWT is issued with Authenticator Assurance Level (AAL) and Authenticator Method Reference (AMR) claims. Those claims support full or selective enforcement through restrictive Postgres Row Level Security policies, including checks that require aal2 or require it only for users with verified MFA factors; planned additions include WebAuthn, FIDO2 devices, and email notifications."
---

# Multi-factor Authentication via Row Level Security Enforcement

[Supabase](https://yomu.fyi/company/supabase) · joel,kangmingtay,stojan · Dec 14, 2022

**Type:** Announcement

## Summary

Supabase announces the release of multi-factor authentication (MFA) for everyone and describes dashboard Single Sign-On (SSO) as preparation for a future SAML release; SSO is available on Enterprise plans by contacting the company. The implementation starts with Time-Based One-Time Passwords (TOTP), where an authenticator generates a short-lived code from a shared secret and the current time, exchanged through a QR code or entered manually. Enrollment uses /enroll, /challenge, and /verify, while subsequent sign-ins require a challenge and verification before a JWT is issued with Authenticator Assurance Level (AAL) and Authenticator Method Reference (AMR) claims. Those claims support full or selective enforcement through restrictive Postgres Row Level Security policies, including checks that require aal2 or require it only for users with verified MFA factors; planned additions include WebAuthn, FIDO2 devices, and email notifications.

## Context

MFA was built in response to customer requests for enhanced security related to compliance, client requirements, or general account protection. The announcement also presents dashboard SSO as preparation for releasing SAML.

## Approach / What changed

The implementation uses TOTP with secrets exchanged through QR codes or manual entry, and separates enrollment and verification with /enroll, /challenge, and /verify endpoints. Successful verification adds AAL and AMR claims to JWTs, which can be checked in restrictive Postgres Row Level Security policies for full or selective MFA enforcement.

## Takeaways

- TOTP codes are six digits and typically valid for 30 seconds or less; the example uses SHA1, six digits, and a 30-second period.
- The challenge endpoint separates MFA initiation from verification, supporting flows such as requesting a challenge before using a Yubikey.
- PostgreSQL policies are permissive by default and combine with an OR clause, so policies must be marked restrictive when multiple MFA checks need to apply.

**Tags:** [Authentication](https://yomu.fyi/topic/authentication), [Postgres](https://yomu.fyi/topic/postgres)

- Source: [Supabase](https://supabase.com/blog/mfa-auth-via-rls)
- Source URL: https://supabase.com/blog/mfa-auth-via-rls
- Ingested by Yomu: 2026-08-29T01:15:30.608Z

[Read original post](https://supabase.com/blog/mfa-auth-via-rls)