Passkeys for Supabase Auth (Beta)

[fadymak]

We're excited to announce the beta release of Passkeys for Supabase Auth — a passwordless, phishing-resistant credential built on the WebAuthn standard.

With passkeys, users sign in with biometrics (Face ID, Touch ID, Windows Hello), a device PIN, or a hardware security key. Supabase Auth stores the public key needed for verification; private key material remains managed by the user’s authenticator or credential provider.

How does it work?

Each passkey enrollment or sign-in is a WebAuthn ceremony with three steps:

1. Options: the client requests a challenge from Supabase Auth.
2. Ceremony: the browser invokes navigator.credentials.create() (register) or navigator.credentials.get() (sign in), prompting the user to approve with biometrics or a security key.
3. Verify: the signed response is sent back to Supabase Auth, which validates the challenge and either stores the new credential or issues a session.

Supabase Auth uses discoverable credentials, so users don't need to type an email or username — the authenticator resolves the account from the credential it already stores.

Enable passkeys in the Dashboard

Open Authentication → Passkeys in the Dashboard, toggle on Enable Passkey authentication, and fill in your WebAuthn relying party details:

• Relying Party Display Name: human-readable name shown during the passkey prompt (e.g. "My App").
• Relying Party ID: your bare domain (e.g. example.com). No scheme, port, or path.
• Relying Party Origins: up to 5 allowed origins (e.g. https://example.com,https://app.example.com).

The Dashboard pre-fills these from your project's Site URL and project name.

Passkeys can also be configured via the CLI and the Management API.

Use it from your app

Note

The Passkeys API is currently experimental and requires an explicit opt-in as the API may change without notice during the beta phase.

Opt in to the experimental API when creating the client:

import { createClient } from '@supabase/supabase-js'

const supabase = createClient(supabaseUrl, supabasePublishableKey, {
  auth: {
    experimental: { passkey: true },
  },
})

Register a passkey for an authenticated user — typically from a security settings page or right after sign-up:

const { data, error } = await supabase.auth.registerPasskey()
// data: { id, friendly_name, created_at }

Sign in with a passkey — no email or phone needed upfront; the authenticator picks the account:

const { data, error } = await supabase.auth.signInWithPasskey()
// data.session and data.user are set; a SIGNED_IN event is dispatched

Manage passkeys — list, rename, and delete from the current user's account:

const { data: passkeys } = await supabase.auth.passkey.list()

await supabase.auth.passkey.update({
  passkeyId: passkeys[0].id,
  friendlyName: 'Work laptop',
})

await supabase.auth.passkey.delete({ passkeyId: passkeys[0].id })

What we'd like to know from you

• Any bugs or rough edges you hit during passkey registration or sign-in flows.
• Friction when configuring the relying-party settings in the Dashboard, CLI, or Management API.
• Feedback on integrating passkeys in native or mobile flows.
• Suggestions for improving the API ergonomics or documentation.

Drop your feedback in this thread or open an issue.

Related links

• Documentation: Passkey authentication
• Dashboard: Authentication → Passkeys
• JavaScript reference:
  • auth.registerPasskey
  • auth.signInWithPasskey
  • auth.passkey (two-step API)
  • auth.admin.passkey (server-side)

[elyobo]

I haven't implemented a passkey auth flow before, but I have used them to sign into both native apps and websites. When I come unauthenticated to an app or site that I've registered a passkey with I'm prompted to use the passkey in my password manager. Unsure whether that's password manager or site/app initiated - I don't see an API here to determine whether the current unauthenticated user has a passkey available so as to determine whether to initiate the flow though.

[fadymak]

Hey @elyobo 👋 Those prompts are initiated by the browser. It sounds like what you're describing is a Conditional UI, if I'm understanding correctly.

It allows you to automatically prompt the user to select a passkey if they already have one available. You might be able to use the more granular, two-step APIs to pass the paramater, like so:

const credential = await navigator.credentials.get({
  // ...
  mediation: "conditional",
});

We're also going to be adding that parameter to the options of signInWithPasskey shortly (likely as the default behaviour).

Let me know if that's what you had in mind.

[elyobo]

Thanks, that sounds exactly like what I was thinking of. I'll give it a go!

[cullophid]

Holy s*** it really happened.

Great work!

[huggsboson]

Is this supported on local supabase instances for testing? I tried config.toml and tried to work out the management API's without success.

[fadymak]

Hey @huggsboson 👋 It looks like the environment variables were not being correctly propagated from the config.toml to the local Auth container when running supabase start locally.

I've got a PR to address this here: supabase/cli#5401

Sorry about that and thanks for reporting! I'll post back in this thread once it's been merged and a release has been cut.

[huggsboson]

No worries. Yeah let me know. I'll hold off merging mine and test locally after it's out.

[fadymak]

The beta channel v2.103.0-beta.6 should have the latest Passkey config fix. To use beta channel releases, you can follow the instructions here.

It should be landing in stable shortly as well.

Let me know if you run into any issues getting set up!

[ranielzed]

I'm getting a "Browser does not support WebAuthn" error when registering passkeys or even when authenticating. I'm on the latest Chrome and I already use passkeys for other sites. I'm on the latest beta

[huggsboson]

I was able to get this functioning locally while on the beta channel, thanks!

[cgaaf]

Thank you so much for implementing passkeys!

So far it works great on my local dev and my live app which uses cloudflare and sveltekit for the front end.

One question,
How do we get it working on iOS and Android native clients? Any chance this could be implemented in the SDKs for those clients? Is it something that would have to go through a web flow and deep linking in some way?

[fadymak]

Thanks @cgaaf! I'm happy to hear it's been a smooth experience for you so far 🙌

We've added support for some of our native SDKs just recently:

• supabase-swift v2.48.0 — Documentation
• supabase-flutter v2.15.0 — Documentation

[cgaaf]

Wow you got the swift SDK supported already?

I'll be implementing it in my app soon and will give some feedback when I get some real world use out of it.

Supabase Auth team is on 🔥

[luluhimself]

Really excited about passkey support landing... got it working end-to-end on our app already! Ran into one snag specifically when the provider is Dashlane rather than a native authenticator, figured it's worth flagging:

Passkey registration fails with a non-native provider (Dashlane) — server rejects with "illegal base64 data"

Setup: self-hosted Supabase Auth, @supabase/supabase-js@2.108.1, auth.experimental.passkey: true. Calling the high-level supabase.auth.registerPasskey() — no custom credential handling on the client, just the SDK's built-in ceremony.

Repro:

1. Signed in, navigated to account settings, clicked "Add a passkey" (triggers registerPasskey()).
2. When the browser's WebAuthn prompt appeared, chose Dashlane (browser extension) as the passkey provider instead of the OS/browser-native option.
3. Approved the passkey creation in Dashlane.

Result: Registration fails client-side with a generic error. Server-side auth logs show:
POST /passkeys/registration/options → 200 OK
POST /passkeys/registration/verify → 400
error_code: "webauthn_verification_failed"
error: "illegal base64 data at input byte 0"
msg: "400: Invalid credential response"

The options call succeeds fine, so RP ID/origin config isn't the issue — the failure is specifically decoding the credential payload returned via Dashlane.

Environment: Brave 1.91.178 (Chromium 149.0.7827.196, arm64) on macOS 26.5 (Build 25F71). Dashlane extension version not captured.

Question: Is this a known interop gap between Dashlane's virtual/software passkey provider and the server-side WebAuthn verification (e.g. a COSE vs. DER key encoding mismatch, or a serialization edge case in the client's serializeCredentialCreationResponse)? Registering with a native platform authenticator works fine — this only reproduces with Dashlane specifically. Is there a tracked issue or planned fix for broader third-party passkey-manager compatibility?