Maurice
9aab9e7513
A session token was a signed JWT and nothing else. Logout only cleared the cookie, a 30-day "remember me" token stayed valid wherever a copy of it had ended up, and nobody could sign out one device short of changing the password or rotating the JWT secret for everyone. Every session token now carries an id (jti) naming a row in the new user_sessions table (id, user_id, created_at, last_seen_at, expires_at, revoked_at, user_agent cut to 256 characters; no address is kept). The rows live behind UserSessionsRepository and the new sessions domain, whose SessionsService is the one issuer: AuthService.generateToken and the OIDC sign-in both go through it, and sliding renewal re-signs a tracked token under the same id and moves its expiry. verifyJwtAndLoadUser takes the repository and refuses a token whose session is revoked, expired or gone, refreshing last_seen_at at most every five minutes. A token without a jti was issued before this change; it passes until its own expiry (or a password change), so the upgrade signs nobody out, and renewal turns it into a tracked session. Sessions end on logout (the one the request names, verified even when expired), on a password change (all, the device gets a new one), a password reset, an admin setting a password, reset-admin.js, an MFA disable (all but the current one), an admin clearing a user's MFA, and with the account. GET /api/auth/sessions lists the active sessions, DELETE /api/auth/sessions/:id ends one and POST /api/auth/sessions/revoke-others ends all but the current, with their contracts in @trek/shared and two new audit actions. There is no UI for them yet. MCP exposes no account or session tools, so there is no parallel tool to change; an MCP call made with a session JWT as bearer goes through the same check. The token in the login, register, demo-login, MFA and passkey bodies stays for API clients but is marked deprecated in the API docs and in the client type, which never read it. A nightly session-purge job on CronRegistrarService deletes the expired and revoked rows. The migration is 042500. The sessions domain gets its own coverage entry at the 80 floor until a full run measures it.
4.6 KiB
Two-Factor Authentication
What it is
TREK supports Time-based One-Time Password (TOTP) two-factor authentication, compatible with Google Authenticator, Authy, 1Password, and any standard TOTP app. When 2FA is active, you enter a 6-digit code (or a backup code) after your password on each login.
Setting up 2FA
Go to Settings → Account, find the Two-factor authentication (2FA) section and click Set up authenticator.
- A QR code and a text secret are displayed. Scan the QR code with your authenticator app.
Note: The setup session expires after 15 minutes. If you do not complete setup within that window, start again.
- Enter the 6-digit code shown in your authenticator app and click Enable 2FA.
- Save your 10 backup codes. These are single-use codes shown only once, so store them somewhere safe (a password manager, printed paper). Each code has the format
XXXX-XXXX. The Backup codes box offers Copy codes, Download TXT and Print / PDF. - 2FA is now active on your account.
Logging in with 2FA
After entering your email and password, TREK shows a second prompt for your TOTP code. You have 5 minutes to complete this second step before the intermediate session token expires. Enter either:
- The current 6-digit code from your authenticator app, or
- One of your backup codes (format
XXXX-XXXX). Each backup code can only be used once.
Disabling 2FA
Go to Settings → Account and use the Disable 2FA form. You must provide both:
- Your current account password
- A valid TOTP code from your authenticator app
Disabling 2FA signs out every other session of your account: the second factor is what kept a stolen password out of them. The session you disabled it from stays signed in, since it just proved both the password and the code.
Note: You cannot disable 2FA while the admin has required it for all users (see below). Owning a passkey does not lift that restriction.
Admin-enforced 2FA
An admin can require 2FA for all users. Before enabling this setting the admin must have secured their own account with either an authenticator app or a passkey — the server rejects the change otherwise with Secure your own account with two-factor authentication or a passkey before requiring it for all users.
If the setting is active and your account has neither 2FA nor a passkey, any API request after login returns a 403 error and the client redirects you to Settings → Account with a prompt to complete 2FA setup. You cannot use the app until setup is complete. See Admin-Permissions.
A user-verified passkey satisfies this policy the way a TOTP authenticator does: with at least one passkey on your account the API stops blocking you and you never need an authenticator app. That holds even if an admin later turns passkey login off again — an existing passkey keeps satisfying the policy. Real-time sync is the one exception: the WebSocket handshake accepts only TOTP, so a passkey-only account under this policy can use TREK normally but never receives live updates from other members. Nothing tells you — the client simply keeps retrying the connection.
Whether enrolling a passkey is a way out of the lockout depends on the instance. Passkey login is off by default (see Passkeys); where an admin has turned it on, the enrolment endpoints stay reachable while the rest of the API is blocked, so you can add a passkey from Settings → Account instead of setting up an authenticator app. Where it is off, TOTP setup is the only way to unblock yourself — or ask an admin to reset your 2FA.
Admin: You can clear a locked-out user's 2FA with
DELETE /api/admin/users/<id>/mfa(admin session required; it refuses your own account). It also signs that user out of every session. The admin panel has no button for it: the user modal offers only Reset passkeys. See Troubleshooting.
Rate limits
TREK enforces IP-based rate limits to protect against brute-force attacks:
| Endpoint | Limit |
|---|---|
Login (/api/auth/login) |
10 attempts per 15 minutes |
MFA code verification (/api/auth/mfa/verify-login) |
5 attempts per 15 minutes |
Exceeding a limit returns HTTP 429. Wait for the window to reset before retrying.
Demo users
The demo user account cannot enable or disable MFA.
See also: Login-and-Registration · Passkeys · Admin-Permissions · Admin-Users-and-Invites · User-Settings