Definition: Genesis Auth (GenesisAuth) is the built-in authentication layer for published Taskade Genesis apps. Every app you publish gets a production-grade sign-in flow โ OpenID Connect (OIDC) underneath, a branded sign-in screen on the surface โ without writing a single line of auth code or wiring up Auth0, Clerk, or Firebase Auth yourself. Users sign in, the app knows who they are, and you get a secure session on the server. That's the whole contract.
Genesis Auth shipped in Taskade v6.144 as part of the broader push to make Genesis apps first-class production software. It pairs with App Users (v6.151) to give you end-user management built into the app settings.
Why This Exists
Building an app with an AI prompt is fast. Adding sign-in to that app used to be slow. You had to:
- Pick an auth provider (Auth0, Clerk, Firebase, Supabase Auth)
- Sign up and configure their dashboard
- Wire their SDK into your app
- Handle callbacks, session cookies, token refresh
- Configure CORS, redirect URIs, logout flows
- Test the edge cases (expired tokens, revoked sessions, password reset)
This is the work that kills indie projects and slows down enterprise teams. Genesis Auth makes it go away.
When EVE builds your app, auth is already there. When you publish, sign-in already works. When a user shows up, they get a familiar, polished sign-in experience. No provider setup, no SDK integration, no wiring.
The Sign-In Flow
From the end-user's perspective, they click "Sign in," authenticate, and land in the app. From the developer's perspective, they read req.user on the server and useUser() on the client. Everything in between is handled.
What Genesis Auth Provides
| Feature | Out of the box |
|---|---|
| OIDC-compliant sign-in | Yes |
| Branded sign-in page | Yes โ inherits your app's theme |
| Session management | Yes โ secure cookies, token refresh |
| Server-side user identity | Yes โ req.user in your app's backend |
| Client-side user hook | Yes โ useUser() in your app's frontend |
| Logout flow | Yes โ single-click, full session cleanup |
| Revocation | Yes โ revoke from app settings |
| User directory | Yes โ via App Users |
| Social sign-in (future) | Planned |
| Custom domains support | Yes โ works on your own domain |
When EVE Builds, Auth Is Already There
This is the key design decision: Genesis Auth is not something you bolt on after the app is built. It is part of the build process from the first token.
When you ask EVE to "build a CRM that only paying customers can see," Genesis Auth is already the mechanism EVE reaches for. The app gets scaffolded with sign-in, the database schema gets user_id columns, and access control rules are already wired to the authenticated user. You do not have to ask for it.
When you clone an app from the Community Gallery, you get the original author's Genesis Auth configuration, with your own app instance isolated. Cloners do not inherit your users, and you do not inherit theirs.
Custom Domains + Auth
Genesis Auth works on both the default Taskade domain and on your custom domains. The sign-in page is served from the same domain as the app, so browser cookies and session handling work without cross-origin complications. You get:
- Same-domain sign-in (no third-party cookie issues)
- Automatic HTTPS
- Branded URL in the address bar
- Zero configuration beyond pointing your DNS
Revoking Access
Every authenticated session is tracked and can be revoked from the app settings. If a user leaves, you remove them; their session dies immediately. If a laptop is stolen, you revoke all sessions for that user; they have to re-authenticate on every device.
The App Users (beta) surface in Genesis settings is where you see the current list, who is active, and when they last signed in.
Use Cases
Internal tools with access control. Build a dashboard for your company only. Add people one by one; they sign in with the identity you invite.
SaaS apps with paid users. Build a customer portal. Use Genesis Auth for access; use Stripe automation (via the Stripe checkout action) for billing.
Client portals. Build one app per client, each with its own user list, all managed from one Taskade workspace.
Micro-apps for your team. Internal approval flows, status dashboards, intake forms โ anything that benefits from knowing who the user is.
Related Concepts
- App Users โ End-user management for your apps
- Genesis Apps โ What Genesis Auth protects
- Custom Domains โ Where your auth-protected app lives
- App Publishing โ The publish step where auth goes live
- EVE โ Builds apps with auth by default
- Living Software โ Why auth matters for apps that evolve
Frequently Asked Questions About Genesis Auth
What is Genesis Auth?
Genesis Auth is the built-in authentication layer for published Taskade Genesis apps. Every app gets OIDC-compliant sign-in, branded sign-in pages, server-side user identity, and session management โ no auth provider setup required.
Do I need to configure Auth0 or Clerk?
No. Genesis Auth replaces the need for third-party auth providers for most Genesis app use cases. If you need a specific provider (say, your company's existing SSO), you can still integrate one โ but you do not need to for basic authenticated apps.
Does Genesis Auth work on custom domains?
Yes. Genesis Auth runs on the same domain as your app, so it works transparently on both the default Taskade domain and any custom domain you configure.
How do I manage who can sign in?
Use the App Users (beta) surface in your app's settings. You can invite people, revoke access, and see who is currently active.
Do clones of my app share my users?
No. When someone clones your app from the Community Gallery, they get the code structure and Genesis Auth configuration, but their app has its own user list. Your users stay yours.