> ## Documentation Index > Fetch the complete documentation index at: https://archie.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Overview > Archie Auth is the built-in authentication system — email/password sign-in, user management, password reset, and email verification, all per-environment. Archie Auth is the built-in authentication system — email/password sign-in, user management, password reset, and email verification, all configured per-environment. Enable it with one click, and your users can sign up, verify their email, log in, and recover passwords without you wiring any of it up. It's the recommended starting point for new projects: you get bcrypt password hashing, JWT tokens with optional encryption, brute-force protection, customizable email templates, and a full admin user-management panel out of the box. ## What Archie Auth handles | Capability | What you get | | -------------------------- | ----------------------------------------------------------------------------------------------- | | **Email / password** | Sign up, sign in, sign out, with bcrypt-hashed passwords. | | **JWT tokens** | RS256-signed access tokens (15 min default), with optional JWE encryption for sensitive claims. | | **Refresh tokens** | 30-day default, rotated on every use. | | **Email verification** | 6-digit code sent on signup with a 1-hour expiry. | | **Password recovery** | "Forgot password" flow with 6-digit recovery code. | | **Brute-force protection** | Configurable account lockout after N failed logins. | | **Rate limiting** | Per-IP limits on signup and login, per-email on recovery. | | **Admin user management** | Block / unblock, force logout, resend verification from the dashboard. | | **Customizable emails** | Subject, body, and branding per environment. | | **JWKS endpoint** | Public keys exposed at `/.well-known/jwks.json` for external token validation. | ## When to use Archie Auth vs. a third-party provider | Choose Archie Auth | Choose a third-party provider | | ---------------------------------------------------------- | ---------------------------------------------------------- | | You don't already have an identity provider. | You already use Auth0, Clerk, or Cognito. | | Email / password is enough for your users. | You need MFA, enterprise SSO, or rule-based authorization. | | You want zero external dependencies. | You want pre-built sign-in UI components (Clerk). | | You want admin controls without configuring a third party. | You want social login as the only sign-in method. | You can also run Archie Auth alongside other [providers](/features/backend/app-services/authentication-providers/overview) — for example, Archie Auth for email/password and Google for social sign-in, with both writing to the same user record. ## Per-environment isolation Archie Auth configuration, signing keys, and user records are all per-environment. Each [environment](/features/backend/environments/overview) maintains: * Its own auth configuration (password policy, token TTLs, email templates). * Its own RSA signing and encryption keys. * Its own user list. Tokens issued in one environment are not valid in another. Auth configuration is **not copied** when branching environments — you enable it independently in each. ## Where to go next Enable Archie Auth, configure it, and run the full sign-up / sign-in flow. Block, force-logout, and otherwise manage registered users from the dashboard. Password hashing, rate limiting, key rotation, and JWE encryption. Customize verification and recovery emails plus sender branding. GraphQL mutations and queries for every auth operation. HTTP endpoints — `/auth/signup`, `/auth/login`, `/auth/refresh-token`, and the JWKS endpoint. ## FAQ Yes. Each environment is isolated — enable it once per environment that needs auth. Auth configuration is intentionally not copied when branching, so a leaked dev secret can't compromise production. Yes — sign users up via the standard signup endpoint with their existing emails. Passwords have to be reset (you can't import bcrypt hashes from a different cost factor) — the standard recovery flow handles that. For machine-readable user data, use the GraphQL API. All active refresh tokens are revoked. When you re-enable, you can choose whether to drop the `_auth_credentials` table (wiping users) or keep it (so existing users can sign in again). Yes — minimum length, required character classes, max failed attempts, and lock duration are all configurable per environment. See [Security](/features/backend/app-services/authentication-providers/archie-auth/security). Not in the built-in flow today. For MFA, run a third-party provider like Auth0 alongside or in place of Archie Auth.