Media sites have a narrow security problem at signup: a captcha can slow bots, but the session renewal pipeline issued after verification is what an attacker actually tries to steal. The design therefore has to separate session creation, verification, refresh, and revocation, then give each transition its own audit and risk boundary.
Short answer: model create, verify, refresh, and revoke as independent, auditable state transitions, with a short access-token lifetime and a separately protected renewal path.
The constraint is a state machine, not a token setting
I start with four transitions: create a session after captcha verification, verify that session on each sensitive boundary, refresh it under stricter risk checks, and revoke it when the user signs out or an administrator responds to risk. Each transition gets its own event record tying the session to a user, device hint, and decision reason. That relationship is what lets an audit answer “which account used this session?” without trusting a browser-supplied label.
The captcha belongs before create. It is a gate against automated registrations, not proof that a future refresh request is safe. A refresh request should carry the session identity in a server-controlled credential, rotate the renewal credential, and be rejected when the session is revoked or its risk posture changes. Keep the access credential short-lived enough that a stolen value has a bounded window; keep the renewal credential out of page JavaScript when the browser architecture permits it.
