Skip to main content
Authentication is one of the most common things people ask Fabricate to build. Describe who should be able to sign in and what they should see, and Fabricate adds its built-in email-and-password accounts to your app, then wires them into your pages and API routes.

​
Adding Authentication

Just ask:
Or be more specific:
An app that keeps personal records — a tracker, a journal, a CRM — needs accounts even if you don’t ask for them, because every visitor to a published app uses the same database. Fabricate adds sign-in to those apps so one person’s records aren’t shown to the next.

​
What Gets Generated

When you add authentication, Fabricate adds: Database tables:
  • fabricate_auth_users — stores user accounts
  • fabricate_auth_sessions — manages login sessions
  • fabricate_auth_config — stores the app’s sign-in settings
API routes:
  • POST /api/auth/register (also /api/auth/signup) — create account
  • POST /api/auth/login — authenticate and create session
  • POST /api/auth/logout — end the session
  • GET /api/auth/me — return the signed-in user
Frontend:
  • Helpers in src/auth-client.ts that restore the session on load and handle sign-up, login, and logout
  • Sign-up and login screens, plus protected pages, built into your app’s UI

​
Self-Contained Session Auth

Fabricate writes a complete, self-contained authentication system directly into your app — there’s no third-party auth provider to sign up for or configure. Everything runs in your own code and database:
  • Hashed passwords stored in your users table — never plain text
  • Session tokens issued on login and kept in an HttpOnly cookie, so page scripts can’t read them
  • A sessions table in your app’s database to track active sessions and end them on logout
Because the auth code lives in your codebase (src/auth.ts), you own it completely. You can read it, modify it, and export it — with no external dependency or vendor lock-in.

​
Auth Patterns

​
Email + Password (Default)

The built-in pattern. Passwords are hashed with PBKDF2, and a successful login starts a server-side session stored in an HttpOnly cookie. Sign-in with Google, GitHub, or other OAuth providers, and passwordless magic links, aren’t part of the built-in accounts. Fabricate’s built-in sign-in is email and password.

​
Security Best Practices

Fabricate’s generated auth code follows security best practices:
  • Passwords hashed with PBKDF2 and a random salt (not stored in plain text)
  • Session tokens are random, and only a hash of each token is stored, so sessions can be ended on logout
  • Tokens delivered via HttpOnly, Secure cookies to prevent XSS theft
  • Accounts are locked for a while after repeated failed logins
  • Requests from other sites are refused, and input is validated on all auth endpoints

​
Frequently Asked Questions

Yes. Ask Fabricate to add roles: “Add admin and user roles. Admins can access the /admin dashboard, regular users cannot.”
Not with the built-in accounts. Generated apps can’t send email on their own, so email verification and password-reset emails aren’t included.
Sign-in with OAuth providers isn’t built in. Fabricate’s built-in accounts use email and password.
Login creates a random session token, which is delivered to the browser in an HttpOnly cookie. Your app’s sessions table stores only a hash of the token, so sessions can be ended on logout. Both the auth code and the database live in your own app.
No. Fabricate adds a self-contained email-and-password system written directly into your app — hashed passwords, server-side sessions, and a sessions table. There’s no external auth service to sign up for, and no vendor lock-in.