Modelence provides a comprehensive built-in authentication system with support for email/password authentication, email verification, password reset, and session management. This guide explains how authentication works in Modelence and how to implement it in your application.Documentation Index
Fetch the complete documentation index at: https://docs.modelence.com/llms.txt
Use this file to discover all available pages before exploring further.
Overview
Modelence authentication includes:- Email/Password Authentication - User signup and login with email and password
- Session Management - Secure session handling with automatic token rotation
- User Management - User profile and role management
- Email Verification - Optional email verification for new signups
- Password Reset - Secure password reset flow with email tokens
- Hooks - Add custom handlers and error rendering components for your authentication flow
- Rate Limiting - Built-in protection against brute force attacks
- Google Sign-In - OAuth authentication with Google accounts
- GitHub Sign-In - OAuth authentication with GitHub accounts
Where to configure what
Modelence splits authentication configuration across two top-level keys instartApp:
auth: { ... }— authentication lifecycle: validation hooks (validateSignup,validateProfileUpdate), event callbacks (onAfterLogin,onAfterSignup,onAfterEmailVerification, …),generateHandle, OAuth linking behavior, andrateLimits. See AuthConfig and Hooks.email: { ... }— email delivery: the email provider, sender address, and per-flow templates/subjects/redirect URLs forverificationandpasswordReset. See Email Configuration.
email: controls whether and how the verification/reset email is delivered; auth: controls what happens when the user clicks the link (and the rest of the auth lifecycle).
How Authentication Works
Session Management
When a user visits your application, Modelence automatically creates a session:- Session Creation - A secure session token is generated using cryptographically random bytes
- Token Storage - The session token is stored in the database and sent to the client
- Automatic Expiration - Sessions expire after 7 days of inactivity
- Heartbeat Updates - Active sessions are automatically renewed through periodic heartbeat requests
_modelenceSessions collection and tracked with the following properties:
User Authentication Flow
Signup Process
When a user signs up with email and password:- Validation - Email format and password strength are validated
- Duplicate Check - System checks if email already exists
- Validate Signup (Optional) - If provided, validates signup using
validateSignuphook - Password Hashing - Password is securely hashed using bcrypt (never stored in plain text)
- User Creation - User record is created in the
_modelenceUserscollection - Session Linking - The session is linked to the new user
- Email Verification (Optional) - If enabled, a verification email is sent
Login Process
When a user logs in:- Credential Verification - Email and password are validated against stored credentials
- Session Update - Current session is linked to the authenticated user
- User Data - User information is returned to the client
- State Update - Client-side session state is updated
OAuth Account Linking
When a user signs in with an OAuth provider (Google or GitHub) using an email that already matches an existing email/password account, behavior is controlled by theoauthAccountLinking auth config option:
'manual'(default) - The OAuth sign-in is rejected with an error: “User with this email already exists. Please log in instead.” The user must log in with their existing password first and link the provider deliberately.'auto'- The OAuth provider is automatically linked to the existing account, but only when both the OAuth-provided email is verified by the provider and the matching email on the existing account is also marked verified locally. This dual-verification requirement prevents pre-registration account takeover (e.g., someone registering a password account against an email they don’t own, then waiting for the real owner to sign in via OAuth). When auto-linking succeeds, missingfirstName,lastName, andavatarUrlfields are backfilled from the provider profile.
'auto' mode — the sign-in is rejected with the same error.
Once an OAuth provider is linked, subsequent sign-ins with the same provider look up the user directly by the provider’s user ID, regardless of email.
Basic Implementation
Client-Side Usage
Signup
Login
Logout
Update Profile
useSession().
Accessing Current User
API Reference
Client Functions
- signupWithPassword - Sign up with email and password
- loginWithPassword - Log in with email and password
- logout - Log out current user
- useSession - Access current user session
- verifyEmail - Verify email with token
- sendResetPasswordToken - Request password reset
- resetPassword - Reset password with token
Server Types
- AuthConfig - Authentication configuration
- UserInfo - User information type
- dbUsers - User database collection
Error Types
- AuthError - Authentication errors
- ValidationError - Validation errors
- RateLimitError - Rate limit errors