Modern authentication with Supabase and Next.js: what matters

Supabase and Next.js can provide a productive authentication stack. The key is keeping client and server responsibilities separate and making token handling explicit.

Core principles

• Start on the server: sensitive operations such as keys, session verification and reading cookies belong on the server.
• Treat the client as a state consumer: it reads the session and triggers actions without exposing credentials.
• Use Edge where it makes sense for low-latency, lightweight validation, and Node for heavier integrations.

Suggested flow

• Sign in through Supabase Auth UI or a custom email or OAuth flow.
• Store the session through HttpOnly cookies managed by the server-side integration.
• Use row-level security: let Postgres and Supabase enforce RLS instead of reimplementing access-control lists in the application.

Good practices

• Never expose SUPABASE_SERVICE_ROLE to the client.
• Protect server-side routes with middleware or handlers that verify the session first.
• Prefer server actions for sensitive mutations to reduce exposure.
• Enable sign-in and sign-out logs and metrics, and IP blocking when needed.

Common mistakes

• Handling tokens in the client while trying to reproduce server behavior.
• Mixing non-HttpOnly cookies with sensitive state.
• Forgetting RLS and relying exclusively on application-level security.

Conclusion

Supabase and Next.js offer a pragmatic authentication solution when the client/server boundary is respected. Build sensitive logic on the server, expose state to the client, and let the database enforce fine-grained policies through RLS.