domains / families / security / auth-implementation-patterns

auth-implementation-patterns

combined

Master authentication and authorization patterns including JWT, OAuth2, session management, and RBAC to build secure, scalable access control systems. Use when implementing auth systems, securing APIs, or debugging security issues. Implement or review authentication and authorization with explicit token, session and resource-access boundaries.

When to use

• 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

When not to use

• 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
• 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.

Skill page

Conflict

The second copy (sickn33) contains the exact same core instructions as the first copy (rmyndharis) but adds significant material: a worked example, specific inputs/prerequisites, and a detailed limitations section that clarifies security boundaries (e.g., JWT vs. resource ownership, CSRF vs. cookies). The first copy is a strict subset of the second. However, the second copy is from a massive bulk catalog (8290 skills) and includes metadata (risk: critical, date_added) that suggests it is a curated or mirrored version with added context. The first copy is from a smaller, more focused repository. Because the second copy contains the full procedure of the first plus additional constraints and examples that the first lacks, and the first is a clean, minimal version, they overlap but the second has material steps/constraints the first lacks. However, looking closely, the first copy is the 'procedure' and the second is an 'expanded' version. Usually, if one is a strict superset of the other with no conflicting instructions, the superset is the 'authentic' or 'winner' because it contains the full procedure. But the prompt says 'combine' when 'each has material steps or constraints the others lack'. Here, the first copy lacks the 'Worked example', 'Inputs', and 'Limitations' found in the second. The second copy does not have anything the first lacks (it has all the same instructions). Therefore, the second copy is a superset. Is it 'authentic'? The prompt says 'authentic' when one copy is the procedure the others reproduce, shorten, or wrap. The first copy is a shortened version of the second. The second copy is the full procedure. Thus, the second copy is the authentic one. Wait, let me re-read. 'decision is authentic when one copy is the procedure the others reproduce, shorten, or wrap.' The first copy shortens the second. So the second is the authentic procedure. The first is a reproduction/shortening. So decision should be authentic, winner is sickn33. Let me double check if there are conflicts. No conflicts. The instructions are identical. The second just has more. So the second is the source of truth for the full skill. The first is a derivative. Therefore, authentic.