Descope and Supabase show how RLS can enforce app access

At a glance

What this is: This is a developer guide showing how Descope authentication and Supabase row-level security combine to restrict users to their own data.

Why it matters: It matters because IAM teams often stop at login, but real access control for human identities still depends on how application claims, database policies, and lifecycle rules align.

👉 Read Descope's guide to secure Next.js apps with Descope and Supabase

Context

Row-level security is a database control that evaluates each query against policy before data is returned. In identity terms, it is the point where authentication claims stop being symbolic and become enforceable access decisions, which is why app security fails when teams treat sign-in as the end of governance.

For IAM programmes, the important question is not whether a user can authenticate, but whether the application and database both understand who the user is and what they may access. This is a human identity pattern, but the same governance logic also applies to service accounts and machine identities that carry claims into downstream systems.

Key questions

Q: How should teams enforce least privilege in applications that rely on JWT claims?

A: Put the final authorization decision in the system that stores the data, not only in the app that displays it. JWT claims should carry the minimum information needed for policy evaluation, and the policy should check ownership, role, or tenant boundaries on every request. That keeps the access model consistent even when multiple frontends or APIs exist.

Q: When does row-level security become more than a database feature?

A: It becomes a governance control the moment access decisions affect confidentiality, tenancy, or delegated administration. At that point, policy design, claim issuance, and revocation are part of the identity model. If those inputs are weak, the database will reliably enforce the wrong entitlement with perfect consistency.

Q: What breaks when applications trust the frontend to filter data access?

A: The system can expose records through alternate API routes, direct queries, or poorly handled identifiers even when the UI looks correct. Frontend filtering is not a security boundary. The boundary has to sit in the authorization layer that evaluates the actual request against the stored row and the session claims.

Q: How do teams know if claim-based authorization is actually working?

A: Run negative tests that attempt cross-user reads, updates, and deletes, then confirm the database rejects them independently of the user interface. Also check that role changes, disabled accounts, and token expiry remove access on schedule. If any of those conditions fail, the authorization model is weaker than it appears.

Technical breakdown

How Supabase row-level security enforces per-user data access

Row-level security, or RLS, attaches policy logic to a table so every SELECT, INSERT, UPDATE, or DELETE is checked against the current session context. In this pattern, the database does not trust the application to filter correctly. Instead, it compares claims such as user_id against the row being accessed and blocks anything that fails the policy. That shifts access enforcement from code paths into the data layer, where it is harder to bypass accidentally. It also means JWT integrity becomes security-critical, because the claims in the token drive policy decisions.

Practical implication: teams should treat RLS policy design and JWT claim integrity as part of the access control model, not just backend implementation detail.

Why JWT claims become the bridge between authentication and authorization

The sample app signs a Supabase-compatible JWT after Descope authenticates the user, then passes that token to the database client. The token carries the subject claim that Supabase uses to map the session to a specific user. This is a common federated pattern: an identity provider establishes who the user is, then the target system consumes those claims to decide what the user can do. The security boundary sits in the trust relationship between token issuer, token signer, and policy engine.

Practical implication: validate who can mint downstream tokens and ensure claim mapping is explicit, minimal, and consistently enforced across all access paths.

How role claims extend RLS beyond single-owner data

The guide also shows how a role claim can expand policy logic so an administrator may access broader data than a standard user. That turns RLS from simple ownership checking into attribute-based authorization, because the policy evaluates not only who the subject is, but what role they hold. This is useful in multi-tenant apps and delegated admin models, but it also increases the risk of overbroad claims if role assignment is not governed carefully. The access model remains only as strong as the trust in role issuance and revocation.

Practical implication: review role issuance and revocation with the same discipline used for privileged access, especially when roles override default row ownership rules.

NHI Mgmt Group analysis

Authentication without database enforcement is not access control: this guide reinforces a basic but frequently missed governance point. A user session can be valid and still be over-privileged if the application layer alone decides what data is visible. For human IAM programmes, that means the identity claim must survive the journey into the policy enforcement point, otherwise the control is only cosmetic.

Row-level security is a governance boundary, not just an SQL feature: teams often treat RLS as a developer convenience for multi-user apps, but it is really an access model that pushes authorization decisions into the data layer. That matters when business logic, tenancy, and delegated administration all depend on the same claims, because policy drift becomes an identity risk rather than only a coding defect.

Claim quality determines policy quality: the sample design relies on a JWT subject and optional role claims, which is exactly where entitlement errors become visible. If the claim is stale, over-broad, or issued without lifecycle discipline, RLS will faithfully enforce the wrong answer. The practitioner conclusion is that token issuance, claim mapping, and revocation must be governed as one chain.

Named concept: policy-backed access boundary: this is the point where identity assertions become enforceable data access rules. In practical terms, it is the difference between an application that merely knows who logged in and one that can prove the user is only acting within the rows they are entitled to touch. That boundary is the real control surface for least privilege in modern apps.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader identity lens, OWASP NHI Top 10 helps teams map policy gaps before they become access-control failures.

What this signals

Policy-backed access boundary: as applications move more authorization logic into the data layer, IAM teams need a clearer handoff between identity claims and enforcement points. That shift is especially relevant for platforms that mix human users, service accounts, and workflow automation, because the same claim can have very different consequences depending on where it is consumed.

For teams building multi-tenant or delegated-admin applications, the next governance step is to test entitlement decisions at the boundary where the data is actually stored. That makes claim lifecycle, role revocation, and policy review part of one control chain rather than separate engineering tasks.

The practical signal is simple: if a user can authenticate but still reach data they should not see, the access model is incomplete. Identity governance now has to prove that the policy engine, not just the login screen, is the source of truth.

For practitioners

• Bind authorization to the data layer Use row-level security or an equivalent database policy layer for any application where users should only access their own records. Keep the frontend and API honest by making the database the final enforcement point for SELECT, INSERT, UPDATE, and DELETE decisions.
• Treat JWT claims as governed inputs Limit downstream claims to the minimum required for policy evaluation and document exactly which service issues them. Review subject identifiers, role claims, and expiry handling as part of identity governance rather than application plumbing.
• Separate ownership from privilege escalation Use ownership-based rules for standard users and explicit privileged roles for cross-record access, then review those roles under PAM-style governance. This prevents a temporary admin claim from becoming a permanent exception in the policy layer.
• Test policy decisions with negative cases Verify that users cannot read, update, or delete another user’s rows even when they know the resource identifier. Add regression tests that confirm the database rejects cross-tenant access paths, not just that the UI hides them.
• Align lifecycle events with claim revocation When a user is deprovisioned, role-changed, or disabled, ensure the token path and database policy path both stop granting access immediately. Stale tokens and delayed claim updates create a governance gap that RLS cannot fix on its own.

Key takeaways

• Authentication alone does not control access unless the claims it produces are enforced where data is stored.
• Row-level security turns database policy into an identity control, which makes claim quality and revocation discipline critical.
• Teams should test authorization with negative cases, not just happy-path logins, to prove least privilege is real.

Key terms

• 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.
• Json Web Token: A JSON Web Token is a compact, signed token that carries claims between systems so they can verify identity or authorization without consulting a central session store. In practice, its safety depends on strict validation of the signature, issuer, audience, expiry, and algorithm before any trust decision is made.
• Federated Authentication: Federated authentication lets one organisation or platform accept a login performed by another trusted identity system. The application no longer verifies the user directly. Instead, it consumes signed claims or assertions, which makes trust relationships, certificates, and attribute mapping part of the security boundary.
• Policy-Backed Access Boundary: A policy-backed access boundary is the point where an identity claim becomes an enforceable data access rule. It matters because least privilege is only real when the system that owns the data, not just the application, can deny unsafe access.

What's in the full article

Descope's full guide covers the implementation detail this post intentionally leaves for the source:

• The step-by-step Next.js sample app setup for Descope authentication and Supabase authorization.
• The exact JWT signing flow used to pass Descope identity into Supabase policies.
• The SQL policy examples for SELECT, INSERT, UPDATE, and DELETE enforcement in Supabase.
• The role-claim pattern for expanding row-level security to admin access.

👉 The full Descope tutorial shows the sample app flow, JWT setup, and row-level policy details.

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.