auth-implementation
Installation
SKILL.md
Authentication implementation
Implement identity and authorization end to end. Prefer the existing provider. Do not introduce or replace an identity system without an explicit user decision.
Workflow
- Detect framework/router version, auth package and version, database/ORM, session transport, user/account tables, tenant model, middleware or proxy, protected resources, and existing migrations.
- Distinguish authentication from authorization. Write an access matrix for public, signed-in, owner, team member, admin, and service/background paths that actually exist.
- Decide whether a local user mirror is necessary. If it is, model provider identities separately from application users when multiple login methods or providers are possible. Never link accounts from an unverified client-supplied email.
- Ask only when a material choice remains: provider selection, account-linking policy, deletion behavior, organization/tenant model, or whether existing users must be backfilled.
- Use the matching provider reference only after detecting the exact stack and installed version:
- Clerk for current Next.js Clerk protection and verified user synchronization.
- Auth.js for current Auth.js/NextAuth handlers, adapters, sessions, and route protection.
- Supabase Auth for public-profile synchronization and Supabase session handling.
- For Firebase, Auth0, custom JWT, or a provider/database combination not covered, preserve existing code and consult current primary provider documentation instead of adapting an incompatible example.
- Enforce access next to every protected read/mutation. Middleware/proxy may provide broad routing, but it is not the sole authorization boundary.
- For Supabase Data API access, implement RLS and grants with the actual token strategy. Add both
usingandwith checkwhere ownership may change. Service credentials stay server-only; do not create redundant service-role policies when the credential already bypasses RLS. - Make sync idempotent and verifiable. Prefer signed provider webhooks for lifecycle sync, or fetch authoritative provider data on the server for just-in-time sync. Handle create, update, deletion, replay, out-of-order delivery, and backfill.