Skip to main content
IMP supports two login modes, optional Google OAuth, and optional OTP sign-in via email. Authentication state is shared between the frontend (Next.js / NextAuth) and the backend via a common NEXTAUTH_SECRET.

Login modes

Set AUTH_MODE on the frontend to control how users log in: The frontend reads AUTH_MODE and adapts the login page accordingly. The backend reads AUTH_MODE from its own environment and exposes it via the /config endpoint so the frontend knows which login flow to render. Set this variable in both the frontend and backend environments with the same value.

SMTP (required for OTP mode)

There are two separate SMTP variable namespaces:

Frontend variables (EMAIL_SERVER_*)

The frontend’s NextAuth email provider uses these variables for sending OTP sign-in codes:
The EMAIL_SERVER_* variables in the frontend’s NextAuth email provider are different from the SMTP_* variables used by the backend’s email tool. The example repo’s .env.example (which is shared with the backend container) lists SMTP_* variables — those are for the backend’s agent email tool, not for login.

Backend variables (SMTP_*)

The backend exposes an email tool that agents can call to send emails on behalf of users. It reads from these variables (as code reads them in src/templates/tools/email.ts):
Variable name discrepancy. The shared .env.example in the example repo lists SMTP_USERNAME and SMTP_SENDER_EMAIL and SMTP_TLS. The backend code reads SMTP_USER, SMTP_FROM, and SMTP_SECURE. Use the code-level names (SMTP_USER, SMTP_FROM, SMTP_SECURE) when configuring the backend container — the .env.example names for these three variables do not match what the backend reads.

NEXTAUTH_SECRET symmetry

NEXTAUTH_SECRET must be identical in the frontend and backend environments.
  • Frontend — NextAuth uses it to sign and verify session JWTs.
  • Backend — Uses it to verify JWTs from the frontend, encrypt/decrypt stored OAuth tokens, and encrypt agent variable values.
If the values differ, the backend will reject all authenticated requests from the frontend with a 401. Generate a strong value:

Google OAuth (optional)

To enable “Sign in with Google”, set the following on the frontend: When both variables are set, the Google sign-in button appears on the login page. Google OAuth creates IMP user accounts automatically on first sign-in (matching the default role), as long as the email passes any domain restrictions. Optional domain restriction. Set ALLOWED_EMAIL_DOMAINS (comma-separated) to restrict sign-in to specific email domains:
The domains exulu.com and qventu.com are always allowed.

Full variable reference