Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →zebbern/authentication-patterns
Authentication patterns: session vs JWT vs OAuth comparison, provider selection (NextAuth, Clerk, Supabase Auth), security checklist, and common mistakes.
Passed 22 of 22 test cases with the skill, and 21 of 22 without it.
1 fixed21 passed either way0 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
A test case the skill fixed. Same model, same prompt, with and without the skill.
We are starting a new project and need guidance on picking the right authentication strategy and provider. Can you break down the trade-offs between session-based, stateless tokens, social sign-on, and passwordless setups, as well as recommend suitable libraries or managed services?
| Checked | Without skill | With skill |
|---|---|---|
| Recommends Passkeys with OAuth fallback for greenfield applications targeting a modern user experience. | Missed | Passed |
| Includes Lucia among the recommended open-source authentication libraries. | Missed | Passed |
The instructions your model reads when the skill loads.
Reference for implementing secure, production-ready authentication.
Apply this skill when implementing authentication in a project, reviewing existing auth flows for security issues, choosing between auth providers, or migrating between auth strategies. Use the security checklist before shipping any auth-related change.
| Approach | How It Works | Best For | Drawbacks |
|---|---|---|---|
| Session-based | Server stores session in DB/Redis, client holds session ID cookie | Traditional server-rendered apps, apps needing instant revocation | Requires server-side storage, harder to scale horizontally without shared store |
| JWT (stateless) | Server signs token, client sends it on each request | API-first apps, microservices, mobile clients | Cannot revoke without blocklist, token size grows with claims |
| OAuth 2.0 / OIDC | Delegates auth to external provider (Google, GitHub, etc.) | Social login, enterprise SSO, reducing auth responsibility | More complex flow, depends on external provider availability |
| Passkeys / WebAuthn | Cryptographic key pair, no passwords | High-security apps, passwordless UX | Limited browser support legacy, user education needed |
Login → Access Token (short-lived) + Refresh Token (long-lived, rotated)
│
├─ Access Token: 15 min expiry, sent via httpOnly cookie or Authorization header
│
└─ Refresh Token: 7-30 day expiry, stored in httpOnly secure cookie
│
└─ On use: issue new access + new refresh token, invalidate old refresh token
test cases passed, vs 21 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.