Guides / Prompting and shipping

How to Add Login to Your App: Passwords, Magic Links, Google and Roles

How to add user login to an app you built: email and password, magic links, Sign in with Google, roles and permissions, and keeping sessions secure.

Mythex Team · 2026-09-29 · 7 min read

To add login to an app, pick a method — email and password, magic links (a one-time sign-in link sent by email), or "Sign in with Google" — and implement it with a proven auth library or hosted provider rather than from scratch. Then decide what each type of user may do (roles), and enforce that on the server for every page and API request. Sessions should use secure cookies, expire, and end properly on logout.

This guide walks through each choice and the details that separate a working login from a safe one. For the concepts behind it, see what authentication is.

Decide first: do you need login at all?

Login adds friction and responsibility. You need it when:

• Users have private data (their bookings, documents, invoices)
• Users can change things others will see
• You charge for access
• Different people need different permissions (owner vs staff vs customer)

You may not need it for a marketing site, a public directory, or a form that just sends you an email. A waitlist doesn't need accounts; an email field is enough.

The four common login methods

Many apps combine two: Google sign-in plus email magic links is a popular pairing that covers most people without storing any passwords.

Email and password

If you offer passwords, these are the non-negotiables:

• Hash passwords with a slow password-hashing algorithm. OWASP's password storage guidance recommends Argon2id, with scrypt, bcrypt or PBKDF2 as alternatives. Never store passwords in plain text or with a fast general hash.
• Password resets use a random, single-use link that expires, sent to the verified email.
• Don't reveal which emails have accounts. "If that email is registered, we've sent a reset link" is better than "No account found".
• Rate-limit login and reset attempts to slow down password guessing.
• Allow long passwords and password managers; skip rules that force odd character mixes.

Magic links and one-time codes

A magic link is a sign-in link emailed to the user. Clicking it logs them in. A one-time code is the same idea, typed in instead of clicked.

• Links and codes expire quickly and work only once.
• The link should log the user in on the device where they clicked it, and the token must not stay in logs or analytics tools.
• You need reliable email sending — see how to send emails from your app. Test with Gmail and Outlook, and check spam folders.

Sign in with Google (and other OAuth providers)

"Sign in with Google" uses OAuth and OpenID Connect: Google confirms who the user is and tells your app their email and name. Setup, as of September 2026, happens in the Google Auth Platform section of the Google Cloud Console:

1. Create or select a project, and fill in the Branding page — what users see on the consent screen (app name, support email, logo).
2. On the Clients page, create a client of type "Web application".
3. Add your authorized JavaScript origins and redirect URIs — the exact addresses your app runs on and that Google sends users back to after sign-in.
4. Store the client ID and client secret in your app's secrets.

Things that commonly go wrong, per Google's OAuth documentation:

• redirect_uri_mismatch: the redirect address must match exactly, including http vs https, capitalisation and any trailing slash. Add one for your preview address and one for your live domain.
• HTTPS required: redirect URIs must use HTTPS, except localhost during development.
• The state parameter should be checked on return to protect against cross-site request forgery. Good libraries do this for you.

If you only ask for basic sign-in information (name, email, profile), Google says app verification isn't mandatory. Asking for access to users' Gmail, Drive or Calendar is different and requires verification.

Build it or use a provider?

Both of the first two are reasonable. Hosted providers handle more for you but add a dependency and sometimes cost per active user; check current pricing on their sites. Libraries keep everything in your database but leave more for you to configure correctly. Whichever you choose, ask the AI to use it rather than hand-roll password or session logic.

Roles and permissions

Login tells you who someone is. Permissions decide what they can do. Keep it simple at first:

Rules that matter more than the role names:

• Check on the server, every time. Hiding a button in the page doesn't stop anyone calling the API directly.
• Scope by owner. A member fetching "booking 123" should only get it if it's theirs.
• Users can't promote themselves. Ignore role fields sent from the browser on profile updates.
• Default to no access. New routes should require login unless you decide otherwise.

Test it with two accounts: log in as one, note a record's ID, log in as the other and try to open it. Our security checklist has the full test.

Session security

After login, the app remembers the user with a session — usually a cookie. OWASP's session management guidance recommends:

• Session cookies set with Secure (HTTPS only), HttpOnly (unreadable by page scripts) and SameSite
• A new session ID issued on login, and again when privileges change
• An idle timeout and an absolute maximum lifetime, enforced on the server
• Logout that ends the session on the server, not just deletes the cookie
• Sessions invalidated when a user changes their password

Storing login tokens in the browser's local storage is common in tutorials but exposes them to any script running on the page; secure cookies are usually the better default for web apps.

A prompt that covers the essentials

Add user accounts to this app. Users can sign up and log in with email and password, or with Google. Use [library or provider] rather than custom auth code. Hash passwords with Argon2id or bcrypt. Add password reset by email with a single-use link that expires in one hour. Keep sessions in secure, HttpOnly cookies. Protect /dashboard and every /api route so only logged-in users can use them, and make sure users can only see their own projects. Add an "admin" role that can see all users; only admins can reach /admin, checked on the server.

Then test: sign up, log out, log in, reset the password, try a private URL while logged out, and try another user's record.

Common mistakes in AI-built login

• Protection only in the page. The page redirects logged-out users, but the API returns data to anyone.
• Secrets in the browser. OAuth client secrets and auth provider admin keys belong on the server.
• Preview and live URLs mixed up. Google's redirect URI or the reset-email link points at the preview, so login breaks after publishing.
• No email verification. Anyone can sign up as anyone@company.com. Verify email before granting anything tied to that address.
• Testing only the happy path. Try wrong passwords, expired links and a second account.

Adding login in Mythex

On Mythex, login for your app's users is something you add to your app — it's separate from your own Mythex account. Mythex doesn't provide a built-in auth product, so you bring an auth library or provider and its keys:

1. Choose an approach — for example email and password stored in your own database, or a hosted provider's SDK.
2. If you store users yourself, the app needs a database; ask for one in chat or use /database.
3. Put provider keys in project secrets (/secrets or project settings).
4. Use a prompt like the one above, then test in Preview. For Google sign-in, add redirect URIs for both your preview and your published address.

See Add login to your app in the docs. If you're building a paid product, how to build a SaaS MVP covers accounts and billing together.