Harden Existing Authentication — refactor-chain · secure (conditional)

Bundle: refactor-chain (self-diagnosing, self-healing fix-it pipeline). Phase: secure · Prerequisite: do-the-work + refactor-security flagged (or detected) auth risk · Next: review gate. Adaptivity / conditional: Activates ONLY when auth code is detected — the harness auth signal is true (better-auth, @auth0, next-auth, passport deps, or paths matching auth|login|session|oauth|jwt). On a repo with no auth, it stays dormant and yields to the lane.

Purpose

Take the authentication a project already has and make it safer without changing how it feels to use. It refactors existing auth toward current best practice — rotating sessions on login, moving tokens out of localStorage into HttpOnly cookies or the platform Keychain/Keystore, adding OAuth PKCE, setting Secure/HttpOnly/SameSite on cookies, verifying JWT signatures and expiry properly, and (for Auth0-style setups) moving to hosted/ACUL login screens. It preserves behavior: the same users sign in the same way and land in the same place — the mechanics underneath just stop being risky. It never adds a new auth system to a project that doesn't have one; that is out of scope by design.

When to use

• The repo already has auth and someone wants it made safer. Triggers: "harden our auth", "is our login secure", "our JWT/session handling looks off".
• Tokens or sessions are stored or transmitted unsafely. Triggers: "move tokens out of localStorage", "our cookies aren't Secure/HttpOnly", "fix our session handling".
• An OAuth flow is missing modern protections. Triggers: "add PKCE", "our redirect flow looks outdated", "switch to the hosted login page".
• Mobile auth stores secrets insecurely. Triggers: "put tokens in the Keychain/Keystore", "our app saves the token in plaintext".
• Do NOT use to add login to an app that has none (that's a feature build, not a refactor), or as a general security audit (that's refactor-security).