AutoCore Authentication Architecture
Documents email, Google OAuth, access-token, refresh-token, and public-route authentication behavior.
Authentication is API-owned. Email credentials use Argon2id; access JWTs are signed with the configured secret; refresh tokens are opaque, hashed before storage, rotated, and bound to server-side sessions.
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 |
|---|---|
| Registration, verification, login, reset, and password change are implemented; reset responses avoid account enumeration. | |
| Authorization code flow uses state, nonce, PKCE, issuer/audience checks, and verified email when configured. | |
| Access | Bearer access tokens carry user/session/status/role/permission context and expire according to configuration. |
| Refresh | Refresh tokens are generated with secure randomness, stored as hashes, rotated, and revocable. |
| Future providers | Phone and Apple providers remain placeholders and are not documented as active. |
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.