Auth
This skill should be used when adding authentication or authorization to an app or SaaS — login, signup, sessions, tokens, roles, permissions, multi-tenant access, SSO, or social login. Trigger phrases include "add login", "add auth", "sign in with Google", "protect this route", "user roles", "admin permissions", "JWT or sessions", "which auth provider", "RBAC", "multi-tenant access", "who can see what", "magic link", "SSO". It picks the right provider and pattern instead of rolling auth from scratch.From its SKILL.md
npx -y skills add MartinOlivero/saas-builder --skill authAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
4.9 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it
Auth
This skill makes the two decisions every SaaS gets wrong: which auth provider and how to model permissions. It picks a vetted provider over hand-rolled auth, and a permission model that fits the product.
Analogy: auth is the lock and the guest list for your building. You don't forge your own lock (you'd leave it pickable) — you buy a good one and decide who gets which key.
The one rule
Don't roll your own auth. Password hashing, session rotation, OAuth flows, and reset tokens are where subtle, catastrophic bugs live. Use a provider or a battle-tested library. (Pairs with the secure-coding skill, which covers the OWASP auth-failure defenses.)
Discovery (max 3 questions, only if unknown)
- Is this B2C (individual users) or B2B (organizations/teams with members)?
- Do you need enterprise SSO (SAML/OIDC) for buyers — now or soon?
- What's the stack/backend — Supabase, plain Vercel + Postgres, or full-stack TypeScript?
Step 1 — Pick the provider (decision tree)
| Situation | Use | Why |
|---|---|---|
| Building with an agent / on InsForge | InsForge Auth | Agentic-native — the agent wires auth + RLS through its own skills/MCP; every query scopes to the user in SQL. |
| Already on Supabase | Supabase Auth | Free, RLS-native — every query scopes to the user in SQL. Most-proven ecosystem. |
| Want the best React DX / drop-in components, not tied to a backend | Clerk | Best components, orgs/teams built in. ~$0.02/MAU after a free tier. |
| Full-stack TypeScript, want self-hosted control | Better Auth (~28k⭐) | TS-native, framework-agnostic, orgs/RBAC/passkeys/SSO. |
| Enterprise SSO is a buyer requirement | Auth0 / WorkOS | SAML/OIDC, directory sync, the enterprise checkboxes. |
Default for a fresh React + Vite + Postgres SaaS with no SSO need: InsForge Auth if you're building agent-first, Supabase Auth if on Supabase, or Clerk otherwise. All three scope to the user via RLS — match the auth host to the DB host from the data-modeling skill.
Step 2 — Sessions vs JWT
- Classic web app → server-side sessions in an httpOnly, Secure, SameSite cookie. Easy revocation, no token-in-JS exposure.
- Stateless API / mobile / microservices → short-lived JWT access token + refresh token.
- Never store JWTs in
localStorage(XSS-readable). Cookie or in-memory only. - Keep authorization out of the JWT body beyond coarse role hints — baked-in roles go stale until expiry and can't be revoked. Check permissions server-side per request.
Step 3 — Model authorization (RBAC by default)
- Default to RBAC: a small set of roles —
owner / admin / member / viewer. Covers most SaaS. - Add ABAC/policy rules only when access depends on attributes: resource owner, department, plan tier, time. Example: "edit invoice only if
role=managerAND samedepartment." - Centralize the check in one middleware/guard or policy layer. Never scatter
if (role === 'admin')across handlers — that's how a forgotten check becomes a breach.
Step 4 — Multi-tenant scoping (B2B)
- Scope every authz check by
tenant_id/org_id. A valid user of org A must never read org B. - Let Postgres Row-Level Security be the backstop (see the
data-modelingskill) so even a missed app-layer check can't leak across tenants. - Use OAuth/OIDC via the provider for social + SSO logins — never handle raw third-party password flows yourself.
Delegation & fallback
- Provider available → wire it (InsForge/Supabase/Clerk/Better Auth) and configure roles/orgs through it. On InsForge, its
insforgeandinsforge-integrationsskills wire auth — including external providers (Clerk/Auth0/WorkOS) into JWT-based RLS — so the agent sets it up end to end. - No provider chosen / offline → fall back to a well-known library (Better Auth or Lucia), httpOnly cookie sessions, bcrypt/argon2 password hashing, and the RBAC pattern above. Never block on a missing provider.
Output
Deliver: the provider recommendation with a one-line reason, the session/token decision, a concrete role model for this product, the protected-route guard wired in, and the multi-tenant scoping rule if B2B.
Reference
InsForge Auth (~5k⭐, agentic-native), Better Auth (~28k⭐), Auth.js/next-auth (~28k⭐), Clerk, Supabase Auth (part of supabase ~104k⭐).
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most auth identity skills give in ~1.1k tokens
Counted across 408 of the 432 authors here whose files we hold, read 2026-09-06
- Use parameterized queries for all SQL and database access to prevent SQL injectionin 60 of 408, across 40 files
- Hash passwords with bcrypt or Argon2idin 50 of 408, across 34 files
- Store secrets in Vault or environment variablesin 37 of 408, across 17 files
- Add security headers to all responsesin 28 of 408, across 14 files
- Rate limit public endpoints per clientin 22 of 408, across 8 files
- Store tokens in httpOnly cookiesin 21 of 408, across 16 files
- Use HTTPS in productionin 17 of 408, across 4 files
- Apply rate limiting to all API endpointsin 17 of 408, across 9 files
- Validate all input with Bean Validationin 16 of 408, across 3 files
- Enable JWT or OIDC for stateless authenticationin 15 of 408, across 2 files
- Scan dependencies for CVEsin 15 of 408, across 2 files
- Log audit records for sensitive operationsin 15 of 408, across 2 files
Said here and by no other author read
- Use a vetted auth provider or battle-tested library
- Use server-side sessions in httpOnly cookies for classic web apps
- Keep only coarse role hints in JWT bodies
- Default to RBAC with a small role set
- Centralize authorization checks in one middleware or guard
- Enable row-level security as the backstop
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.