Server-Rendered Login Sessions: Creation, Verification, Refresh, Logout, and Phone Recovery

Short answer: for a server-rendered learning app, create a short-lived session only after the phone code is verified, keep refresh as a separate state transition, and make recovery a deliberate path rather than an accidental logout loop. The useful design artifact is an auditable session record tied to a learner, device context, and recovery status. I build RAG and agent features in Python, so I tend to move from a notebook test to a production boundary quickly. Authentication deserves a slower handoff. In an edtech app, a learner may lose a phone while a parent, teacher, or school administrator still needs a safe way to recover the account. The browser should receive only an opaque session cookie; the server owns the lifecycle and records why each transition happened. How should server-rendered login handle session creation, refresh, and logout? Treat the four actions as different state changes. Code verification proves possession of a phone channel. Session creation establishes a browser session. Verification checks whether that session is still active. Refresh extends a valid session under a stricter policy. Logout revokes one session, while an account-recovery event may need to revoke every session. That separation makes failure visible. A refresh request must not silently create a new account. A logout request must not be interpreted as proof that the phone number is still controlled. For a school district, the audit trail should answer: which learner was affected, which session changed, what policy allowed it, and when the change took place. The request flow is intentionally plain: The existing login form sends a verified learner identifier and a server-held code-verification result to the application backend. The backend calls the session creation boundary and stores the returned session identifier in a secure, HttpOnly cookie. Each protected request verifies that session before loading learner data. A still-valid session may refresh through the refresh bound