Authentication
How sign-in works, why it uses bearer tokens, and what that means operationally.
Identity
Identity is managed by Cognito. Accounts are created by administrators; there is no self-registration. Sign-in is institution-agnostic — the same screen serves every role and every tenant, and the account determines what happens next.
Why bearer tokens, not cookies
The application sends a bearer token rather than a host-locked cookie. That is what lets a tenant subdomain and the shared address share one session model, and what lets a developer proxy a local web app at a deployed API without a cookie-domain fight.
Tokens refresh silently while a user works. A session is per browser: signing in on a laptop does not sign you in on a phone.
Scoped tokens
One flow deliberately avoids a full session: the paper-capture handoff. Scanning the QR code opens a capture page holding a short-lived, narrowly scoped token that permits uploading scans to one session and nothing else. A teacher does not sign in on a phone to photograph scripts.
Guests
Open Quiz guests hold no session at all. The link token identifies the quiz, an attempt is bound to a single session so it cannot be restarted, and a guest can reach nothing else.
Operational notes
- Password resets are performed by an administrator and take effect immediately.
- Rejected credentials are far more often a password mismatch than a missing account.
- Session identifiers are rotated on a role switch rather than reused.