Skip to main content
When your app needs users to sign in, Creator provisions a complete authentication system: a private identity provider (user pool) for your project, plus working sign-up, sign-in, email-confirmation, and forgot-password pages already wired into the app. The agent brands those pages to match your design — it doesn’t reinvent the security underneath them.

​
What your users get

  • Email + password accounts, with email confirmation on sign-up (a verification code is sent; users confirm before their first sign-in).
  • Password reset by email.
  • Social sign-in — “Sign in with Google” or GitHub — when you ask for it. Generic single sign-on with providers like Microsoft Entra, Okta, or Auth0 is also supported via standard OIDC.
  • Sessions that are validated on every request, server-side.

​
What you may be asked to do

Email/password auth needs nothing from you — it works out of the box. Social sign-in needs two things only you can provide, because the OAuth app lives in your Google/GitHub account:
  1. Create the OAuth client in the provider’s console (the agent tells you the exact redirect URL to allow).
  2. Paste the client ID and client secret into the secure credential field the product shows you — never into the chat.

​
Managing your app’s users

Ask the agent — it can create invited/seed accounts (the user receives a temporary password by email and sets their own on first sign-in), look up users, list them, and delete them. For invite-only apps, self-signup can be paired with your own activation flow.

​
Good to know

  • One user pool per project. Your app’s users exist only in your project — they are completely separate from every other app built on Creator, and from your own Creator account.
  • Passwords are never stored by your app. The identity provider is the only credential store; the app’s database keeps at most a profile row linked to the user’s ID.
  • Portable by design. The auth configuration your app uses is standard OIDC — if you export your code, it authenticates against any standards-compliant identity provider, not a proprietary one.
  • Not in v1: multi-factor authentication and magic-link sign-in. If your app needs them, say so early — don’t assume them.
Sign-in is one of the things verification actually exercises: the checks confirm a wrong password is rejected and that protected pages really are protected.