Notifications
Clear all
Topic starter
16/08/2026 1:13 pm
TL;DR: A Next.js todo app can use authentication, authorization, and row-level security to keep users scoped to their own records, according to Descope’s guide. The governance lesson is that app-level access still depends on database enforcement, not just sign-in success.
NHIMG editorial — based on content published by Descope: Build Secure Apps With Next.js, Supabase, and Descope
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Treat JWT claims as governed inputs Limit downstream claims to the minimum required for policy evaluation and document exactly which service issues them.
- 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.
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.
👉 Read Descope's guide to secure Next.js apps with Descope and Supabase →
Row-level security with Descope and Supabase: what teams need to know?
Explore further
16/08/2026 1:14 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Descope and Supabase show how RLS can enforce app access
