No Code Authentication

Authentication is one of the most security-critical parts of any web application, yet it is also one of the most commonly implemented incorrectly. Custom authentication systems introduce risk at every layer: password hashing algorithms, session management, token rotation, CSRF protection, and rate limiting all need to be implemented correctly. A single vulnerability in any of these areas can compromise your entire user base. Fabricate reduces this risk by seeding reviewed auth modules that already use vetted primitives - PBKDF2 through WebCrypto for password hashing and opaque HttpOnly cookies for sessions - rather than improvising a scheme per project.

When you tell Fabricate to add user accounts, it adds the auth layer directly into your project: users and sessions tables in the app's SQLite database, registration and login endpoints, and a guard that refuses anonymous API requests. Passwords are hashed with PBKDF2 and never stored or logged in plain text. Because the code lives in your repository, you can read it, test it, and change it - there is no vendor SDK between you and your own user data.

The user experience layer is generated to match your application's design system. Login and signup screens are created with your app's color scheme, typography, and layout patterns. These are not generic modal overlays but fully integrated pages that feel native to your application.

Role-based access control goes beyond simple admin and user distinctions. Fabricate can generate complex permission systems where different roles have access to different features, pages, and API endpoints. The AI automatically creates middleware that checks permissions before rendering protected content or processing API requests, ensuring your authorization logic is consistent across the entire application.

For applications that require team or organization features, Fabricate can generate multi-tenant access with workspace isolation on request. Users can belong to multiple organizations, each with its own set of roles and permissions. Invitations, team management interfaces, and organization switching are generated on top of the built-in accounts when you describe them.

Authentication is built into your own project rather than delegated to a hosted identity vendor. When an app needs accounts, Fabricate seeds reviewed auth modules - src/auth.ts on the server and src/auth-client.ts in the browser. They keep users, sessions, and auth config in the app's built-in SQLite database, inside its Durable Object, and depend on nothing but WebCrypto.

The API surface is a small set of routes in your app's server: register (or signup), login, me, and logout. Registration hashes the password with PBKDF2 before it is ever written. Login verifies the hash, creates a server-side session, and sets an opaque HttpOnly cookie; logging out removes the session on the server rather than merely deleting a cookie. Repeated failed logins trigger a lockout.

Every other anonymous API request is refused with 401 by default. Protected routes resolve the session user and scope their queries to that user's id, and state-changing requests must pass a same-origin CSRF check before storage is touched.

Anything beyond this baseline is generated on request rather than assumed. OAuth providers, email verification delivery, multi-factor authentication, extra roles, and organization or multi-tenant models are all things you ask for in plain English; the AI extends the same tables and checks instead of bolting on a parallel system. Fabricate uses Clerk to sign you in to fabricate.build - that is the platform account, not the auth inside the apps you generate.