Skip to content
TriedDocs
Account and security

Sign-in and two-factor authentication

Email and password, Google, SSO and the development sign-in, password reset, closing public sign-up, sessions and TOTP two-factor authentication.

The dashboard supports several sign-in methods. Which ones appear depends on how the API is configured. All of them end in the same place: a signed, HttpOnly session cookie (tried_session) bound to one user and one workspace.

The Tried sign-in page

Sign-in methods#

Method How it works Needs
Email and password Sign in with email and password, then Sign in, Create an account or Forgot password? Nothing
Google Continue with Google (OpenID Connect) GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET Needs keys
OIDC SSO Enter an email on a domain with SSO; you are redirected to your identity provider An SSO configuration (see SSO, SAML and SCIM)
SAML POST /auth/saml/start with the email finds the workspace's SAML configuration and returns the IdP redirect A SAML configuration
Development sign-in Continue with email: no password, for local development ENABLE_DEV_LOGIN (on by default outside production)

GET /auth/methods tells the sign-in page which methods are on:

{ "password": true, "google": { "enabled": true, "mock": true }, "dev_login": true }

Without Google credentials, a built-in mock identity provider stands in for Google in development (mock: true). Mock identity providers are off in production unless ENABLE_MOCK_AUTH=1 is set.

Warning

The API refuses to start with NODE_ENV=production while ENABLE_DEV_LOGIN is on, or while SESSION_SECRET or INTERNAL_TOKEN still have their development values.

Email and password#

  • Passwords need at least 8 characters (maximum 200). They are hashed with bcrypt.
  • Emails are trimmed and lowercased, so Sam@Example.com and sam@example.com are the same account.
  • A first sign-in with no workspace creates one for you, with a Default key.
  • If an account already exists for the email through Google or SSO, sign-up asks you to use Forgot password? to add a password instead.
  • A wrong email and a wrong password return the same message (Wrong email or password), and the check takes the same time either way, so the response does not reveal which emails have accounts.

Rate limits on sign-in#

Endpoint Limit per minute
POST /auth/login 30 per IP and 10 per email
POST /auth/signup 10 per IP
POST /auth/password/forgot 10 per IP and 3 per email
POST /auth/password/reset 10 per IP
POST /auth/password/change 10 per user

Over the limit, the API returns 429 with Too many ... attempts. Try again in Ns.

Reset a password#

Click Forgot password?, enter the email and click Send reset link. The page always says If that email has an account, a reset link is on its way.

Open the email#

The link goes to /reset-password?token=... and works for 1 hour. Each link works once. Email is sent through SMTP when SMTP_URL is set; otherwise it is written to the API log.

Choose a new password#

Setting the password signs out every session for that user, invalidates any other unused reset links, and signs you in. If 2FA is on, you are asked for a code first.

Signed-in users can change their password with POST /auth/password/change (current_password, new_password). This signs out the user's other sessions and keeps the current one.

Close public sign-up#

Set DISABLE_SIGNUP=1 on the API to stop new accounts from being created with email and password. POST /auth/signup then returns 403 with Sign-up is closed. Ask your workspace admin for an invite. Existing users can still sign in, and invited people can still join through their invite link.

Sessions#

Property Value
Cookie tried_session, signed, HttpOnly, SameSite=Lax, Secure in production
Lifetime 30 days
Scope One user in one workspace; switching workspace updates the session
Sign out POST /auth/logout deletes the session and clears the cookie

Sessions end early when you reset your password (all sessions), change your password (other sessions), leave a workspace, or are deprovisioned through SCIM.

Two-factor authentication#

Tried supports TOTP codes from an authenticator app such as 1Password, Google Authenticator or Authy. 2FA is per user and applies to every sign-in method that Tried checks itself: password, Google, development sign-in and password reset.

Settings, Security: two-factor authentication and OIDC single sign-on

Start setup#

Go to Settings, Security, find Two-factor authentication and click Set up 2FA. Scan the QR code, or enter the key shown under Scan the code, or enter this key manually.

Confirm a code#

Type a code from the app in Code from the app and click Turn on.

Save your recovery codes#

The Save your recovery codes dialog lists one-time codes. Each code works once if you lose your device. They are not shown again. Use Copy all, store them safely, then click I've saved them.

At sign-in, after the first factor, the page asks for Two-factor authentication: Enter the 6-digit code from your authenticator app, or a recovery code. The first factor is valid for 5 minutes. A used recovery code is removed.

To turn 2FA off, click Turn off and enter a code from your app or a recovery code. Turning 2FA on and off is recorded in the audit log as auth.2fa_enable and auth.2fa_disable.

API Purpose
GET /auth/2fa enabled and recovery_codes_remaining
POST /auth/2fa/setup Returns secret and otpauth_url
POST /auth/2fa/enable { "code": "123456" }, returns recovery_codes
POST /auth/2fa/disable { "code": "..." }
POST /auth/mfa/verify { "mfa_token": "...", "code": "..." } during sign-in
Note

2FA is optional per user. There is no setting that forces 2FA for every member of a workspace. When people sign in through your SSO or SAML identity provider, enforce MFA there.