Authentication & Authorization Implementation Patterns
Build secure, scalable authentication and authorization systems using industry-standard patterns and modern best practices.
Use this skill when
- Implementing user authentication systems
- Securing REST or GraphQL APIs
- Adding OAuth2/social login or SSO
- Designing session management or RBAC
- Debugging authentication or authorization issues
Do not use this skill when
- You only need UI copy or login page styling
- The task is infrastructure-only without identity concerns
- You cannot change auth policies or credential storage
Instructions
- Define users, tenants, flows, and threat model constraints.
- Choose auth strategy (session, JWT, OIDC) and token lifecycle.
- Design authorization model and policy enforcement points.
- Plan secrets storage, rotation, logging, and audit requirements.
- If detailed examples are required, open
resources/implementation-playbook.md.
Safety
- Never log secrets, tokens, or credentials.
- Enforce least privilege and secure storage for keys.
Resources
resources/implementation-playbook.md for detailed patterns and examples.
Worked example
Input: an Express application accepts a user's login and keeps the pre-login session ID. Read the bundled playbook, regenerate the session after credential verification, save only required identity fields, and verify that the old cookie cannot access /api/profile. Also test failed login, logout and store failure. Expected: successful login changes the session ID; failed login grants no access.
Inputs and prerequisites
Record the installed framework/SDK versions, identity provider, tenant model, credential store and test environment. Supply project-specific database adapters and request schemas; examples are integration sketches, not a runnable identity service.
Limitations
- JWT validation does not establish resource ownership; enforce tenant and object policy on reads and writes.
- Refresh rotation requires atomic persistence and concurrency tests; the issuance example alone does not provide it.
- Cookie flags do not replace CSRF protection, and secure-cookie behavior needs the actual HTTPS/proxy configuration tested.
- Provider integrations and password policies must be checked against current primary documentation and the application's threat model.
1---2name: auth-implementation-patterns3description: Implement or review authentication and authorization with explicit token, session and resource-access boundaries.4---5
6
7# Authentication & Authorization Implementation Patterns
8
9Build secure, scalable authentication and authorization systems using industry-standard patterns and modern best practices.
10
11## Use this skill when
12
13- Implementing user authentication systems
14- Securing REST or GraphQL APIs
15- Adding OAuth2/social login or SSO
16- Designing session management or RBAC
17- Debugging authentication or authorization issues
18
19## Do not use this skill when
20
21- You only need UI copy or login page styling
22- The task is infrastructure-only without identity concerns
23- You cannot change auth policies or credential storage
24
25## Instructions
26
27- Define users, tenants, flows, and threat model constraints.
28- Choose auth strategy (session, JWT, OIDC) and token lifecycle.
29- Design authorization model and policy enforcement points.
30- Plan secrets storage, rotation, logging, and audit requirements.
31- If detailed examples are required, open `resources/implementation-playbook.md`.
32
33## Safety
34
35- Never log secrets, tokens, or credentials.
36- Enforce least privilege and secure storage for keys.
37
38## Resources
39
40- `resources/implementation-playbook.md` for detailed patterns and examples.
41
42## Worked example
43
44Input: an Express application accepts a user's login and keeps the pre-login session ID. Read the bundled playbook, regenerate the session after credential verification, save only required identity fields, and verify that the old cookie cannot access `/api/profile`. Also test failed login, logout and store failure. Expected: successful login changes the session ID; failed login grants no access.
45
46## Inputs and prerequisites
47
48Record the installed framework/SDK versions, identity provider, tenant model, credential store and test environment. Supply project-specific database adapters and request schemas; examples are integration sketches, not a runnable identity service.
49
50## Limitations
51
52- JWT validation does not establish resource ownership; enforce tenant and object policy on reads and writes.
53- Refresh rotation requires atomic persistence and concurrency tests; the issuance example alone does not provide it.
54- Cookie flags do not replace CSRF protection, and secure-cookie behavior needs the actual HTTPS/proxy configuration tested.
55- Provider integrations and password policies must be checked against current primary documentation and the application's threat model.