## Problem
When users set up two-factor authentication (TOTP) in the dashboard, the
enrollment modal asks them to name their authenticator app, with the
placeholder suggesting `e.g.: Google Authenticator`. Many users keep or
type this example name without realizing it is simply a custom nickname
for the factor.
On the sign-in MFA screen (`SignInMfaForm.tsx`), the code input
previously rendered its label as:
> `Code generated by Google Authenticator`
This phrasing can lead users to believe that Supabase has locked their
account specifically to Google's authenticator app—even when they
actually scanned the QR code with Apple Passwords / iOS Keychain,
1Password, or Bitwarden. As reported in #51502, users who rely on their
iPhone's built-in authenticator can get alarmed, thinking their
authentication setup was unexpectedly swapped.
Furthermore, if a user is genuinely locked out (e.g. lost device and
backup codes), the "Email support" option previously only surfaced after
an explicit authentication exception occurred, rather than being readily
discoverable under the *"Unable to sign in?"* help section.
Closes#51502
## Solution
1. **Clear, standard form label & descriptive subtext**:
- Replaced the ambiguous `Code generated by [Friendly Name]` label with
a standard `Authentication code` label.
- Moved the factor's friendly name into the field description:
- When a name is configured: `From the authenticator app registered as
[Friendly Name]`
- Fallback when no name is set: `From the authenticator app registered
to this account`
- This makes it immediately obvious that `[Friendly Name]` is just the
custom label they chose, rather than a hard vendor requirement.
2. **Direct support escape hatch**:
- Added an **"Email support to regain access"** link directly into the
*"Unable to sign in?"* list in both `SignInMfaForm` and
`SignInRecoveryCodeForm`.
- Users who are stuck now have an immediate, obvious way to reach out
without needing to trigger errors or hunt down the support email.
3. **Extracted testable helper logic**:
- Extracted friendly-name normalization and support mailto generation
into a dedicated `SignInMfa.utils.ts` module.
- Added unit test coverage in `SignInMfa.utils.test.ts` (9 tests
covering trims, null/empty cases, and mailto parameters).
## Review instructions
1. Navigate to `/sign-in-mfa` (with an account that has a TOTP factor
enrolled).
2. Verify that the input label reads `Authentication code`.
3. Check the subtext: verify that it clarifies `From the authenticator
app registered as [Name]`.
4. Inspect the *"Unable to sign in?"* section at the bottom:
- Confirm that "Email support to regain access" is visible and opens a
pre-addressed email to `support@supabase.com` with subject `Unable to
sign in via MFA`.
5. Check `/sign-in-recovery-code` and verify the same support link is
present.
## Checklist
- [x] I have read
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
- [x] Unit tests added and passing (`vitest run
components/interfaces/SignIn/SignInMfa.utils.test.ts`)
- [x] Code passes Prettier formatting check
- [x] Code passes ESLint without adding warnings
## What kind of change does this PR introduce?
Allow users to sign in using a recovery code after being redirected to
the MFA verification page.
## Additional context
<img width="435" height="373" alt="image"
src="https://github.com/user-attachments/assets/968fd15e-3081-4aa2-b645-4e0d2ec2637c"
/>
<img width="494" height="404" alt="image"
src="https://github.com/user-attachments/assets/fd7cee49-dca7-4f1a-873a-293e21c68faa"
/>
## How to test
- Enable MFA on your account if needed
- Generate recovery codes if needed (make sure you actually saved the
recovery codes somewhere)
- Sign out
- Sign in and when redirected to the MFA verification page, click the
_Authenticate using a recovery code_ link
- Enter one recovery code
Check that:
- you're signed in
- when on [your account security
page](https://studio-staging-git-gildasgarcia-auth-1624-dashb-177251-supabase.vercel.app/dashboard/account/security),
you have one less code available
Then:
- Disable the `enableAuthRecoveryCodes` config cat flag
- Sign out
- Sign in and wait on the MFA verification page
Check that:
- the _Authenticate using a recovery code_ link is not displayed
- Accessing [the recovery code sign in
page](https://studio-staging-git-gildasgarcia-auth-1624-dashb-177251-supabase.vercel.app/dashboard/sign-in-recovery-code)
redirects you to the MFA page
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added recovery-code authentication as an alternative MFA sign-in
method.
* Added a dedicated recovery-code sign-in page with validation,
visibility controls, cancellation, and sign-out options.
* Added a link from the MFA sign-in screen when recovery codes are
available.
* Added loading and error states while checking recovery-code
availability.
* **Bug Fixes**
* Prevented valid recovery-code sign-ins from being redirected back to
the MFA prompt.
* Limited recovery-code settings to accounts with exactly one enrolled
authenticator.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Ali Waseem <waseema393@gmail.com>
Efekan