Emergent Auth (built-in)
What is Emergent Auth?
Emergent Auth is the platform's built-in authentication and user-management system. Every app created on Emergent automatically includes authentication capabilities - no third-party service or complex configuration required.
When you describe user sign-up, login, or access control in your chat prompt, the AI agents wire up Emergent Auth behind the scenes. User credentials, sessions, and profile data are stored securely within your app's environment.
Note
Emergent Auth is included at no additional cost. You don't need API keys, OAuth apps, or separate billing for auth providers.
How it works
Emergent Auth provides:
- Google sign-in - users can sign in with their Google account (no Google Cloud credentials required for basic use; supply
/GOOGLE_CLIENT_ID
only if you need custom consent-screen branding or extra scopes such as Gmail/Calendar).GOOGLE_CLIENT_SECRET - Email and password login - users sign up and log in with an email and password.
Login runs on the hosted auth.emergentagent.com page. The "Secured by Emergent" branding is present on this page and cannot be removed on any tier.
The underlying user data lives in your app's MongoDB database, so you can query and extend it just like any other collection.
Typical usage in prompts
You interact with authentication by describing what you want in natural language. For example:
- "Users should be able to sign up with email and password, then log in to see their dashboard."
- "Add a login page. Only logged-in users can create posts."
- "Add Google sign-in."
The agents will generate login and sign-up UI, wire up backend endpoints, enforce route protection, and handle sessions - all using Emergent Auth.
Security best practices
Emergent Auth follows industry-standard security practices out of the box:
- Passwords are never stored in plaintext; they are hashed using bcrypt or Argon2.
- Sessions use secure, HTTP-only cookies with
andSameSite
flags in production.Secure - Rate limiting is applied to login and sign-up endpoints to mitigate brute-force attacks.
- HTTPS is enforced for all production apps.
Tip
If your app handles sensitive data (health, finance, etc.), describe additional requirements in your prompt - e.g., "Require two-factor authentication" or "Log all login attempts." The agents will implement these features.
Switching to a third-party auth provider
If you later decide to migrate to an external provider (e.g., Clerk, Supabase Auth, Auth0), you can instruct the agents to refactor your app:
- "Replace Emergent Auth with Clerk for authentication."
The agents will update routes, remove the built-in session logic, and integrate the new provider's SDK. User data migration may require additional steps depending on the provider.
