Architecture
Transport, strategy, backend, and the four persistence entities.
Layers
| Layer | Role | Code |
|---|---|---|
| Transport | Reads/writes the session token on HTTP (Bearer header or cookie) | aura_auth.transport |
| Strategy | Validates credentials and returns a user (e.g. password on a credential account) | aura_auth.strategies.password |
| Backend | Implements BackendProtocol — CRUD for users, accounts, sessions, verifications | aura_auth.backend.sqlalchemy |
| Orchestration | AuraAuth, UserManager — register, login, sessions, verification helpers | aura_auth.app, aura_auth.manager |
Contracts (protocols, schemas, config, exceptions, security helpers) live in aura_auth._core. Higher layers depend on protocols, not on each other’s concrete types.
Four tables
- User — identity:
name,email,email_verified,image, timestamps. - Account — one row per sign-in method:
provider_id(e.g."credential"),account_id, optional OAuth fields,password(hashed) for credential accounts. - Session — opaque
token,user_id,expires_at, optional IP / user agent. - Verification — short-lived rows for email verification, resets, etc.
Login creates a session row; current_user resolves the token against the session table, then loads the user by id. This is not a stateless JWT login flow (though TokenHelper remains available for other signing needs).
Request flow (login)
- Client posts email/password to
POST /auth/login. - Password strategy finds the credential account, verifies bcrypt, returns the user.
- UserManager creates a session with a new opaque token.
- Response returns
AuthResponse; transport may set Bearer in the body only, or alsoSet-Cookiewhen cookie transport is enabled.