Go Server-Rendered Login Controls: Auditable Session Verification Through Password Recovery

Short answer: For a server-rendered Go login, keep session creation, verification, refresh, and logout under one server-side policy, then make password recovery revoke old sessions and emit an audit trail before it creates a new one. The page reaches on-call as a symptom, not a diagnosis: a learner completes /forgot-password , lands on /login again, and support can't tell whether the old browser session was revoked. The least complex design that survives the audit is an opaque cookie backed by a server-side session record, with recovery tokens kept separate from login sessions. That choice does add a stateful lookup to authenticated requests. It also gives the platform team a place to enforce expiry and revocation without trusting the browser to report its own status. No magic here. The page starts at the end of the audit chain The first alert should describe the user-visible control that failed: password recovery completed, yet session revocation did not complete within the authorization-change SLO. A raw rise in 401 responses isn't enough because it mixes expired cookies, revoked sessions, invalid credentials, and application mistakes into one noisy count. The useful page carries a correlation ID, the affected flow, and the oldest incomplete state transition; it does not carry a password, recovery token, or raw session identifier. Work backward from that page. A defensible event chain is recovery_requested , recovery_credential_verified , password_changed , sessions_revoked , and, when policy permits it, new_session_created . The names are local choices rather than a standard, but their order represents the control being audited: the temporary recovery credential proves only that the password may be changed, while the login session authorizes later requests. Combining those credentials makes expiration and revocation harder to explain, so keep separate hashes, lifetimes, and consume paths. Consider two tabs submitting the same recovery form. Both requests may pass