SecureStartKit
SecurityFeaturesPricingDocsBlogChangelog
Sign inBuy Now
Home/Glossary/Custom Access Token Hook
Authentication

Custom Access Token Hook

Also known as: Auth Hook, access token hook

Definition

A Custom Access Token Hook is a Supabase Auth Hook that runs a Postgres function on every JWT issuance to inject custom claims. Typical uses include adding tenant_id and role claims for multi-tenancy, which then become readable inside RLS policies via auth.jwt().

What is a Custom Access Token Hook?

A Custom Access Token Hook is a SQL function registered with Supabase Auth that runs during every access-token issuance, including the initial sign-in and every refresh-token exchange. The function receives the user record and returns a JSON object of claims that get merged into the JWT payload.

What goes in a Custom Access Token Hook?

Multi-tenancy: query the user's tenant membership and inject tenant_id and role claims. RBAC: inject the user's role for downstream RLS policies. Audit context: inject a customer tier or feature flag set so the database can scope behavior without an extra round trip.

Why inject claims into the JWT instead of querying per request?

Performance. RLS policies running on every query cannot afford a per-query lookup of the user's tenant or role. With the claim in the JWT, the policy reads auth.jwt() ->> 'tenant_id' for zero database overhead. Refreshes pick up changed claims because the hook re-runs on every refresh, so role changes propagate within the refresh-token cycle.

Learn more

  • Supabase Multi-Tenancy + RBAC: The Secure Pattern
  • Supabase JWT + Session Management

Related terms

  • JWTA JWT is a signed, base64url-encoded token carrying claims about a user. Supabase issues JWTs after authentication, signs them with ES256 asymmetric keys (default for new projects since October 2025), and Next.js apps validate them server-side via getClaims without a network round trip to the auth server.
  • Row Level SecurityRow Level Security is a Postgres feature that filters which rows of a table each user can see or modify. In Supabase apps, RLS policies are written in SQL and evaluated on every query against the authenticated user's JWT claims, making the database itself the authorization boundary.
  • getClaimsgetClaims is the Supabase Auth method that locally validates a JWT against the cached public key from the project's JWKS endpoint and returns the parsed claims. It replaces getSession for authorization because getSession reads the cookie without re-validating the signature.
← Back to full glossary
SecureStartKit

The security-first Next.js SaaS template. Auth, payments, and everything you need to launch - with backend-only data access, Zod validation on every input, and built-in optimization for AI coding agents.

Summarize with AI

Product

  • Security
  • Features
  • Pricing
  • FAQ
  • Docs
  • About

Use Cases

  • For Indie Hackers
  • For Solo Developers
  • Fintech SaaS
  • Internal Tools
  • Healthtech SaaS

Free Tools

  • All Tools
  • RLS Policy Generator
  • Security Checklist
  • Security Headers
  • JWT Decoder
  • JWT Generator
  • CORS Config Generator
  • JSON to Zod Converter
  • API Key Generator
  • Stripe Webhook Verifier
  • Stripe Fee Calculator
  • SaaS Pricing Calculator
  • Tech Stack Costs
  • OG Image Preview

Compare

  • All comparisons
  • vs ShipFast
  • vs Makerkit
  • vs Supastarter
  • vs Divjoy
  • vs Nextbase
  • One-time vs subscription

Resources

  • Blog
  • Glossary
  • Security Patterns
  • Changelog
  • Contact
  • Privacy
  • Terms

More from the same maker

  • AppScreenshotStudio
  • QueryScope
  • FrictionScope
  • MCP Hunter
  • BookIllustrationAI
  • MyCVCraft
  • StyleMyFade

© 2026 SecureStartKit. All rights reserved.

Built with SecureStartKit