Skip to main content

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.

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

CapabilityWhat you get
Email / passwordSign up, sign in, sign out, with bcrypt-hashed passwords.
JWT tokensRS256-signed access tokens (15 min default), with optional JWE encryption for sensitive claims.
Refresh tokens30-day default, rotated on every use.
Email verification6-digit code sent on signup with a 1-hour expiry.
Password recovery”Forgot password” flow with 6-digit recovery code.
Brute-force protectionConfigurable account lockout after N failed logins.
Rate limitingPer-IP limits on signup and login, per-email on recovery.
Admin user managementBlock / unblock, force logout, resend verification from the dashboard.
Customizable emailsSubject, body, and branding per environment.
JWKS endpointPublic keys exposed at /.well-known/jwks.json for external token validation.

When to use Archie Auth vs. a third-party provider

Choose Archie AuthChoose 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 — 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 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

Getting started

Enable Archie Auth, configure it, and run the full sign-up / sign-in flow.

User management

Block, force-logout, and otherwise manage registered users from the dashboard.

Security

Password hashing, rate limiting, key rotation, and JWE encryption.

Email templates

Customize verification and recovery emails plus sender branding.

GraphQL API

GraphQL mutations and queries for every auth operation.

REST API

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.
Not in the built-in flow today. For MFA, run a third-party provider like Auth0 alongside or in place of Archie Auth.