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.
At a glance
What this is: This is a developer tutorial showing how passkeys can replace a Supabase Auth login flow while preserving Supabase Row Level Security through a Descope session and JWT translation step.
Why it matters: It matters because IAM teams need to see where human authentication ends and application authorization begins, especially when passwordless login must still map cleanly into database access controls.
Context
Passkeys are a passwordless human authentication method, but they do not remove the need to translate identity into the format downstream systems expect. In this tutorial, the problem is not passkey adoption itself, but how a Supabase app continues to authorize users after the login method changes.
The integration pattern centers on a Descope session, a Supabase-compatible JWT, and Row Level Security that still depends on the user_id claim. That makes this a human IAM implementation question with workload-facing consequences, because the application must preserve authorization semantics while changing the login experience.
Key questions
Q: How should teams implement passkeys when Supabase still enforces Row Level Security?
A: Treat passkeys as the human authentication layer and keep a separate, verified token translation step for Supabase. The application must mint a Supabase-compatible JWT with the right subject claim so Row Level Security can still evaluate user context correctly. Authentication can change without breaking authorization, but only if the identity mapping stays stable.
Q: What breaks when a passwordless login flow does not preserve downstream identity claims?
A: Database authorization breaks first, because the relying system can no longer interpret who the user is in policy terms. In a Supabase-style design, the login may succeed while RLS still fails if the token lacks the expected subject, uses the wrong identifier type, or is signed with the wrong secret.
Q: How can security teams know whether passkey adoption is actually improving security?
A: Look for fewer phishing-driven account compromises, lower reliance on password resets, and consistent enrolment success across user groups. Also check whether recovery and device-change scenarios remain controlled, because a passkey programme that works only in the happy path is not mature.
A: Yes, because the policy inputs may change even if the business application does not. Identity provider swaps often alter subject format, claim names, and recovery flows, so teams should review authorization logic, schema assumptions, and account recovery before cutover rather than after users are already authenticating.
Technical breakdown
How passkey login changes the authentication boundary
Passkeys replace passwords with device-bound authentication, usually backed by biometrics or a hardware authenticator such as a YubiKey. In the article’s flow, the human user authenticates to Descope, which becomes the identity system that establishes the session. Supabase is not performing the primary login step anymore; it receives a translated identity artifact instead. That distinction matters because authentication and application authorization are now separated across two systems, and the trust handoff depends on the session token and subsequent JWT construction.
Practical implication: Treat the upstream passkey login as the human authentication control and validate the downstream token handoff separately.
Why Supabase needs a compatible JWT after Descope login
Supabase expects a JWT signed with the project secret and a valid sub claim so it can map the caller to a database identity. The article’s backend route takes the Descope user ID, signs a new JWT, and returns it to the frontend for Supabase client initialisation. This is a translation layer, not just token passing. If the claim format, signing secret, or subject mapping is wrong, Supabase cannot apply its authorization logic correctly, including Row Level Security decisions.
Practical implication: Design the token exchange as an authorization boundary and verify that the subject claim matches the database identity model.
How Row Level Security survives an authentication-provider swap
Row Level Security depends on consistent identity attributes, not on which login screen the user saw. The article notes that Descope user IDs are usually strings rather than UUIDs, so schemas and policies may need adjustment. That means existing access policy logic can survive a provider swap only if the application’s identity model, claim parsing, and Postgres functions are aligned. The security risk is not passkeys themselves, but breaking the identity-to-policy mapping when the authentication source changes.
Practical implication: Review RLS policy inputs and database user-id assumptions before switching authentication providers.
NHI Mgmt Group analysis
Passwordless login does not eliminate identity translation risk: The central governance issue in this pattern is not whether passkeys are secure, but whether the application can still map the authenticated human to the right authorization context. Once authentication moves to one system and database authorization remains in another, the handoff becomes part of the control surface. Practitioners should treat that handoff as an identity design decision, not just an implementation detail.
JWT subject mapping is the real control point: In a Supabase-plus-passkey architecture, the sub claim is the authoritative bridge between upstream authentication and downstream access control. If the claim format or identity type changes, policy enforcement can drift even when the login experience looks correct. The named concept here is identity translation gap: the distance between who authenticated and what the authorizer can actually understand.
RLS only works when identity semantics stay stable across layers: Row Level Security is often discussed as a database feature, but in practice it is an identity dependency. Schema assumptions such as UUID versus string identifiers can quietly determine whether policy evaluation still matches the logged-in user. Teams should therefore govern RLS as part of the human IAM lifecycle, not as an isolated database setting.
Passkeys shift the burden from memorized secrets to trust plumbing: Removing passwords reduces phishing and reuse exposure, but it also increases the importance of session handling, claim integrity, and backend token issuance. That is a healthier control model only when every downstream system consumes identity consistently. Practitioners should focus on the interoperability layer, because that is where the security outcome is actually decided.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: AI Agent Identity Security Buyer's Guide
What this signals
Identity translation gap: Passwordless authentication only reduces risk when the upstream login method and downstream authorization model agree on the subject being authorised. In Supabase-style deployments, the fragile point is not biometrics but the JWT handoff and the identity fields the database expects.
If the application changes login providers but leaves Row Level Security assumptions untouched, access control can fail silently. That is why IAM teams should treat claim mapping, subject typing, and policy evaluation as one control chain rather than separate implementation tasks.
For practitioners
- Validate the identity handoff Confirm that the authenticated Descope session produces a Supabase-compatible JWT with the correct sub claim and signing secret before database access is enabled.
- Align database identifiers with the new identity source Check whether existing Supabase schemas and Row Level Security policies assume UUID user IDs, then update functions and policy logic if Descope string IDs are now authoritative.
- Separate authentication from authorization testing Test passkey login, JWT issuance, and RLS enforcement as distinct control points so a successful biometric login does not mask a broken policy decision downstream.
- Review fallback paths for account recovery Define how users regain access if passkey enrolment fails or a device is lost, so recovery does not force insecure manual exceptions into the login flow.
Key takeaways
- Passkeys improve human authentication, but they do not remove the need to translate identity into the format an application authorizer can use.
- The critical control is the JWT handoff from the login system to Supabase, where the subject claim determines whether Row Level Security still works.
- Teams moving to passwordless login should test policy mapping, schema assumptions, and recovery paths together, not as isolated configuration steps.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63B — Authentication | Passkeys are a human authentication method, and the article centres on replacing passwords with them. |
| Recommendation — Apply SP 800-63B to validate that the passkey flow satisfies authentication requirements before changing downstream authorization. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on preserving database authorization after authentication changes. |
| Recommendation — Map token claims to PR.AA-05 so authorization remains consistent when the login method changes. | ||
| OWASP ASVS | V6 — Authentication | The tutorial is an authentication implementation pattern for a web application. |
| V8 — Authorization | Row Level Security enforcement is the downstream authorization control being preserved. | |
| V10 — OAuth and OIDC | The article discusses a token exchange and session-driven login flow across systems. | |
| Recommendation — Use V6 to verify the passwordless login flow and confirm the application accepts the intended authenticated subject. Use V8 to check that authenticated identities are authorised correctly after JWT translation. Apply V10-style review to confirm the identity handoff and token issuance are consistent across systems. | ||
Key terms
- Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
- Row-Level Security: Row-level security is a database control that restricts which rows a session can read or modify based on policy. For multi-tenant apps, it is valuable because it pushes tenant enforcement below application code, reducing the chance that a forgotten filter exposes another organisation's data.
- JWT Subject Claim: The JWT subject claim identifies who the token represents in a machine-readable way. In application architectures, it becomes the bridge between authentication and authorization, so mismatched identifiers or inconsistent claim generation can cause a correct login to produce the wrong access decision.
- Identity Translation: Identity translation is the process of converting one system’s authenticated user context into the format another system can authorise. It is common in federated and multi-service architectures, and failures in translation often look like policy problems even when the root cause is an identity mapping mismatch.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on August 16, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org