AutoCore Sessions and Credential Recovery
Explains session listing, revocation, password reset, verification, and cookie boundaries.
Session controls are explicit. The refresh cookie is HttpOnly and uses secure production defaults; the access token is not accepted from a raw cookie. Password reset and password change revoke sessions according to the audited service behavior.
Release candidate source
This article reflects the audited AutoCore source revision 7a504f6e430c16d4fcb03ebdea3cc3fb7816df60 and immutable release-candidate tag v1.0.0-rc.1 at 9edfb109f44cc80385784c694b96392cfc04e70f. Configuration and external provider behavior remain deployment-dependent.
Source boundary
| Control | Source-verified behavior |
|---|---|
| Cookie | Refresh cookie name and lifetime are configured; SameSite and Secure behavior are applied by the HTTP utility. |
| Revocation | Users may revoke one or all sessions; Admin revocation is permission-gated and audited. |
| Reset | Reset tokens are hashed, short-lived, single-use, and all sessions are revoked after a successful reset. |
| Verification | Email verification tokens are hashed, expire, and are consumed once. |
| Return URL | OAuth return paths are restricted to same-site paths rather than arbitrary redirects. |
High-risk operation
Use explicit authorization, a written reason, a confirmation gate, and post-action verification. Documentation does not grant permission to change a deployment.
Operational controls
Use the smallest verified control for the task. Keep provider, host, legal, and operator responsibilities separate from application behavior. When a control is not implemented or not verified, leave it disabled or mark it as a limitation.
Verification
Verify the route, relevant API or configuration state, negative path, audit/evidence result, and public effect before closing the task. Record unknown or configuration-dependent behavior as a limitation.