Skip to main content
Docs/App Auth (End-Users)
DocsLogins for your app
Free

Logins for your app

Add sign-up and login so every person who uses your app gets their own account and sees only their own data. Choose Google Sign-In, email + password, magic link, or any mix.

What it does

Logins give every person who uses your app their own account. Once someone signs in, your app can greet them by name, save their work, and show only their own records - so two different users never see each other's data. It is the building block behind profiles, "my orders", saved favorites, dashboards, and anything that should be private to one person.

You pick how people sign in. Google Sign-In is fastest for users who already have a Google account, magic link is the easiest because there is no password to remember, and email + password is the familiar option for users who log in repeatedly across devices. You can offer more than one, and they work together for the same account.

Available on every plan, including Free.

How to add it

Just ask in chat - for example, "add login so each user has their own account" or "let people sign in with Google." GenMB adds the sign-up and login screens, wires them to your app, and saves only what each user is allowed to see. You can follow up to change the look, switch sign-in methods, or gate certain pages behind login.

The AI also auto-detects when your app needs accounts from your original prompt. You can turn methods on or off any time in the Services panel, and the sign-in flow updates on your next save.

Auth Methods

Your generated app can authenticate end-users with any combination of:

Google Sign-In

Zero-config OAuth flow. Fastest for users who already have a Google account.

Email + Password

Classic signup / login with bcrypt-hashed passwords. OTP confirms email before account is created.

Magic Link

Passwordless. User receives an email with a one-time link that signs them in.

Methods are additive. A user can sign up with email + password and later use Google Sign-In for the same account if their Google email matches.

Sessions

Once someone signs in, your app remembers them until they sign out or their session expires - they do not have to log in again on every visit. Sign-ins are kept separate per app, so a user logged into one of your apps is not automatically logged into another, even with the same email. This keeps each app's user list independent.

Because sign-ins are scoped per app by design, if you want one shared account across several of your apps, mention that in chat so it can be set up deliberately.

Limits

  • Magic-link rate limit: 3 sends per email+app per 15-minute window, 10 per IP.
  • OTP (email confirmation code) lifetime: 15 minutes.
  • Pending signup details are held for 15 minutes before they expire.
  • Only your own deployed app can trigger sign-in - other sites cannot call your app's login.
  • Available on all plans, including Free.

For developers

Everything below is optional. GenMB writes this for you when you ask in chat - it is here if you want to wire the auth SDK by hand or understand exactly what runs.

Google Sign-In

GenMB hosts the OAuth client and callback. You do not need to register a project in Google Cloud or copy a client secret.

await window.genmb.auth.signIn()           // opens Google popup, returns when done
const user = window.genmb.auth.getUser()   // { id, email, name, avatarUrl } or null
await window.genmb.auth.signOut()

Email + Password

1

Sign up requested

User submits email + password. The platform validates password strength, stages a hash in Redis, and emails a 6-digit OTP.
2

OTP verified

User enters the code. The account is created in appUsers/{appId}~{email} and a session cookie is set.
3

Subsequent logins

POST email + password; on match, a fresh session cookie is set.
4

Forgot password

User requests reset; an OTP is emailed; user submits new password + OTP to update the hash.
Signup-enumeration is mitigated: reset-request and signup endpoints always return a generic 200 so an attacker cannot use them to discover registered emails.

The simplest UX. User enters an email and clicks the link in the message GenMB sends. The SDK auto-verifies the token on page load via ?magic_token=... and the user is signed in.

await window.genmb.auth.sendMagicLink({ email: 'user@example.com' })
// User clicks email link; redirected back signed in.

SDK Usage

All methods funnel into a unified window.genmb.auth object so your UI code does not need to branch on method:

window.genmb.auth.getUser()             // current user or null
window.genmb.auth.onChange(user => {})  // subscribe to sign-in / sign-out
await window.genmb.auth.signOut()       // works for any method

Combine with RBAC to gate features by role, and with app data to scope records to user.id.

Under the hood

  • Accounts live in appUsers/{appId}~{email}, separate from platform (GenMB) users.
  • Passwords are hashed with bcrypt before storage; plaintext never lands in the database.
  • Sessions live server-side in appAuthSessions, referenced from a genmb_auth_session cookie scoped to your app domain. The cookie is HttpOnly and Secure, so it cannot be read from JavaScript.
  • Reset-request and signup endpoints always return a generic 200 so they can't be used to discover which emails are registered.

FAQs

How is this different from the auth I use to sign into GenMB?
Two separate systems. Platform auth (Google OAuth on genmb.com) is for you, the GenMB user. App auth is for end-users of the apps you generate. App users live in a separate appUsers/{appId}~{email} collection so they never collide with platform users.
Which auth method should I pick?
Magic link is the easiest UX for end-users (no password to remember). Email + password is best when users expect to log in repeatedly from many devices and might re-use a password manager. Google Sign-In is fastest for users who already have a Google account. The AI picks what your prompt implies; you can override in the Services panel.
Can I use more than one method in the same app?
Yes. Methods are additive. An end-user can sign up with email + password and later use Google Sign-In for the same account if their Google email matches.
Where do sessions live?
In a server-side appAuthSessions collection, gated by the genmb_auth_session cookie. The cookie is scoped to your app's domain. Sessions expire automatically; refresh is handled by the SDK.
Are passwords stored safely?
Passwords are hashed with bcrypt before storage; the plaintext never lands in the database. Password validation requires minimum strength before signup is allowed.

Ready to build?

Create your first app for free, no credit card required.