SecureStartKit
SecurityFeaturesPricingDocsBlogChangelog
Sign inBuy Now
Home/Glossary/getClaims
Authentication

getClaims

Also known as: supabase.auth.getClaims, getClaims()

Definition

getClaims 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.

What does getClaims do?

getClaims() extracts the access token from the session cookie, fetches the project's public key from the JWKS endpoint (cached after first call), verifies the JWT signature locally with the Web Crypto API, and returns the parsed claims as a typed object. Validation happens in microseconds and produces the same cryptographic guarantee as a network call to Supabase Auth.

When should you call getClaims vs getUser?

For server-side authorization in Server Actions, Route Handlers, and middleware, use getClaims(). It is faster than getUser() (no network round trip) with the same security guarantee. Use getUser() only when you need user data that is not in the JWT claims, such as a fresh email_verified flag.

What is wrong with getSession?

getSession() reads the cookie and returns whatever is there without verifying the signature. If the JWT signing key has been rotated, or if an attacker forged a JWT, getSession cannot tell. The Supabase docs explicitly discourage getSession for authorization since the asymmetric-keys release in October 2025.

Learn more

  • Supabase JWT + Session Management in Next.js
  • getSession vs getUser: which is safe server-side

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.
  • AALAAL (Authenticator Assurance Level) is a JWT claim that reflects how strongly the user authenticated. AAL1 means one factor (password, OAuth, magic link). AAL2 means a second factor verified for this session (TOTP code). RLS policies read `auth.jwt() ->> 'aal'` to gate sensitive operations.
  • @supabase/ssr@supabase/ssr is the official Supabase package for server-side authentication in Next.js, SvelteKit, and other SSR frameworks. It manages JWT storage in httpOnly cookies, handles the OAuth and magic-link callback cookie writes, and exposes createServerClient and createBrowserClient helpers for each context.
← 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