Notifications
Clear all
Topic starter
16/08/2026 1:11 pm
TL;DR: Passwordless login still depends on careful identity translation between systems, not just a better login method, according to Descope. Its tutorial shows how passkeys can be added to a Supabase app by replacing the existing auth flow, generating a Supabase-compatible JWT from a Descope session, and preserving Row Level Security with minimal schema changes.
NHIMG editorial — based on content published by Descope: Add passkeys to Supabase with Descope
Questions worth separating out
Q: How should security teams adopt passkeys for infrastructure access?
A: Start with the highest-risk interactive accounts, especially administrators who are exposed to phishing and push fatigue.
Q: Why do passkeys improve security but still require IAM governance?
A: Passkeys improve security by reducing phishing and secret theft, but IAM governance is still required because identity risk moves to enrollment, device trust, and recovery.
Q: What breaks when the identity provider and database use different user ID formats?
A: Policies often break at the claim-to-schema boundary.
Practitioner guidance
- Align subject claims with downstream policy logic Verify that the identity claim used in the session token matches the database and policy model before changing authentication methods.
- Review token issuance immediately after login Generate the application token only after the passkey session is validated and the identity attributes needed by the database are present.
- Test row-level policies against new identity formats Run access tests for read, write, and forbidden paths using the post-passkey token shape so policy failures appear before rollout.
What's in the full article
Descope's full blog post covers the implementation detail this post intentionally leaves at the governance level:
- The exact Next.js code pattern for exchanging a Descope session for a Supabase-compatible JWT
- The backend route example used to sign the token and pass the user identity through to Supabase
- The flow editor steps for adding passkeys to the Descope login journey
- The schema and policy adjustments needed when Supabase user IDs are not UUIDs
👉 Read Descope's passkey integration guide for Supabase authentication →
Passkeys in Supabase auth flows: what changes for IAM teams?
Explore further
16/08/2026 1:13 pm
Passwordless login does not simplify identity governance, it shifts where the complexity lives. Passkeys remove password reuse and phishing exposure, but the control problem moves into token exchange, claim integrity, and policy consistency. That means the IAM team still owns the trust boundary, only now it sits between the authenticator and the database layer. The practical conclusion is that passwordless adoption is an identity architecture decision, not just a UX upgrade.
A question worth separating out:
Q: How should teams govern passkey recovery and device replacement?
A: Treat recovery as a controlled identity lifecycle event, not an informal support task. Require proof of identity, define when a lost device invalidates a prior passkey, and ensure the old credential cannot be reused after re-enrollment. Otherwise the strongest login method can still leave stale access behind.
👉 Read our full editorial: Passkeys for Supabase modernize human authentication without passwords
