What Is Authentication? Logins, Sessions and OAuth Explained
Authentication is how an app confirms who a user is. How passwords, sessions, tokens, OAuth and roles work, and what to ask your AI builder when adding login.
Mythex Team · · 6 min read
Authentication is how an app confirms who a user is — usually by checking something they know (a password), something they have (a code sent to their phone or email) or an identity from another trusted service (such as "Sign in with Google"). Once a user is authenticated, the app remembers them with a session or token so they don't have to log in on every page. Deciding what that known user is allowed to do is a separate step called authorization.
Why it matters when you build with AI
Adding login is one of the most common requests people make to an AI builder, and one of the easiest to get subtly wrong. A login page is simple to generate. The hard part is everything around it:
- Are passwords stored safely?
- Does every private page and every API endpoint actually check who's asking?
- Can a logged-in customer see another customer's data by changing a number in the URL?
- What happens when someone forgets their password?
An app can look perfectly secure while failing every one of those. Understanding the moving parts lets you ask the right questions and test the right things.
An everyday analogy
Think of checking into a hotel.
At the front desk you show ID. That's authentication: proving who you are. The receptionist then gives you a key card. That card is your session: for the rest of your stay you don't show ID again; you tap the card.
The card opens your room, the gym and the lift to your floor — but not other guests' rooms or the staff office. That's authorization: what your identity is allowed to access. If you lose the card, the hotel can deactivate it at the desk (revoking a session). When you check out, it stops working (logging out, or expiry).
"Sign in with Google" is like a hotel accepting a letter from a trusted partner saying "this is who they are," instead of checking your ID itself.
The main login methods
| Method | How it works | Pros | Cons |
|---|---|---|---|
| Email + password | User picks a password; the app stores a hash of it | Familiar, no outside dependency | You must store hashes safely and handle resets |
| Magic link / one-time code | App emails a link or code that logs the user in | No passwords to leak or forget | Depends on email delivery; slower to log in |
| Social login (OAuth / OpenID Connect) | User signs in with Google, Apple, GitHub, etc. | Fast for users; no password stored by you | Setup with each provider; users without those accounts |
| Hosted auth provider | A service such as Clerk, Auth0 or Supabase Auth handles sign-up, login and resets | Less security work for you | Monthly cost at scale; another dependency |
| Multi-factor (MFA / 2FA) | A second check after the first, such as an authenticator app code | Much harder to break into | A little more friction |
How passwords should be stored
A secure app never stores your actual password. Instead it stores a hash: the output of a one-way function that turns the password into a fixed string. When you log in, the app hashes what you typed and compares the result with the stored hash.
Two details make this safe:
- A salt — a random value added to each password before hashing, so two people with the same password get different hashes, and precomputed lookup tables are useless.
- A slow algorithm made for passwords — such as Argon2, bcrypt or scrypt. General-purpose hashes like MD5 or SHA-256 are far too fast on their own; attackers can try billions of guesses.
Hashing isn't the same as encryption. Encrypted data can be decrypted with a key; a password hash is designed not to be reversible at all.
Sessions vs tokens
After login, the app needs to recognise you on each request. There are two common approaches.
| Session (cookie) | Token (e.g. JWT) | |
|---|---|---|
| What the browser holds | A random session ID in a cookie | A signed token containing user info and an expiry |
| Where login state lives | On the server, in a database or store | Inside the token itself |
| Logging someone out everywhere | Easy: delete the session on the server | Harder: the token stays valid until it expires unless you keep a block-list |
| Typical use | Traditional web apps | APIs, mobile apps, services talking to each other |
For cookies, three settings matter: HttpOnly (JavaScript on the page can't read the cookie), Secure (sent only over HTTPS) and SameSite (limits sending it on requests from other sites). Storing tokens in the browser's localStorage is common but exposes them to any script that runs on the page.
OAuth and "Sign in with Google"
OAuth 2.0 is a standard for delegated authorization: it lets an app get limited access to your account on another service — say, reading your Google Calendar — without ever seeing your Google password. You're sent to Google, you approve specific permissions (called scopes), and Google gives the app a token for just those permissions.
OAuth on its own was designed to grant access, not to say who you are. OpenID Connect (OIDC) is a layer on top of OAuth 2.0 that adds identity, which is what "Sign in with Google" or "Sign in with Apple" uses. To set it up you register your app with the provider and get a client ID and client secret; the secret stays on your server.
A worked example: login for a client portal
Say you're building a portal where a design agency's clients see their projects and invoices.
- Authentication: clients log in with email and a magic link, so there are no passwords to manage. Agency staff log in with Google Workspace accounts.
- Roles: each user has a role —
clientorstaff. - Authorization rules:
| Action | Client | Staff |
|---|---|---|
| See their own company's projects | Yes | Yes |
| See other companies' projects | No | Yes |
| Upload a file to a project | Own projects only | Yes |
| Mark an invoice paid | No | Yes |
- Where it's enforced: on the server, for every request. The server looks up the logged-in user, then only returns projects where
project.company_idmatches the user's company. Hiding the "Mark paid" button isn't enough — the endpoint itself has to refuse.
Common terms explained
| Term | Meaning |
|---|---|
| Authentication (AuthN) | Confirming who someone is. |
| Authorization (AuthZ) | Deciding what they may do. |
| Session | The app remembering you're logged in, between requests. |
| Cookie | A small piece of data the browser sends back to the site with each request. |
| JWT | JSON Web Token: a signed, compact token carrying claims such as user ID and expiry. |
| Role / permission | Labels like admin or member that decide access. |
| MFA / 2FA | Requiring a second proof, such as a code from an authenticator app. |
| SSO | Single sign-on: one login (often a company account) for many apps. |
| 401 vs 403 | "Who are you?" (not authenticated) vs "You can't do that" (not authorised). |
Common mistakes and misconceptions
- Checking permissions only in the page. If the browser hides a button but the API doesn't check, anyone can call the API directly.
- Trusting IDs from the URL.
/invoices/1042must check that invoice 1042 belongs to the logged-in user. - Rolling your own crypto. Use well-known libraries or providers; don't let the AI invent a hashing scheme.
- Weak password reset. Reset links should be single-use, expire quickly and not reveal whether an email has an account.
- Mixing up your login with your builder's. Your app's users are separate from your account on the tool you build with.
- No rate limiting on login. Without it, attackers can try passwords endlessly.
What to ask your AI builder for
- "Add sign-up and login using [a well-known library or provider]. Don't write custom password hashing."
- "Store passwords hashed with bcrypt or Argon2."
- "Use HttpOnly, Secure cookies for the session."
- "Add roles: admin and member. List every endpoint and which roles may call it."
- "Enforce on the server that users can only read and edit their own records. Then show me how you checked."
- "Add password reset with single-use links that expire in an hour."
- "Rate-limit login attempts."
Then test it yourself: create two accounts and try to reach one's data while logged in as the other. Our guide to adding login and security checklist go further.
Authentication in Mythex
Mythex doesn't provide a built-in auth product for your app's users; you choose an approach — email and password stored in your project's database, or a hosted provider's SDK — and ask the agent to add it. Provider keys go in project secrets, not in chat. This is separate from how you sign in to Mythex itself. The docs recipe on adding login to your app has a starter prompt you can adapt, and what an API is explains where those server-side checks live.
Questions
What is the difference between authentication and authorization?
Authentication checks who you are, for example by verifying your password. Authorization decides what you're allowed to do once you're known, such as whether you can see the admin page or edit someone else's booking. Apps need both.
What is OAuth?
OAuth 2.0 is a standard that lets an app get limited access to your account on another service without seeing your password. 'Sign in with Google' uses OpenID Connect, an identity layer built on top of OAuth 2.0, so the app learns who you are from Google.
Should my app store passwords?
Never in readable form. If you use email and password login, passwords must be stored as salted hashes made with a slow algorithm designed for passwords, such as Argon2 or bcrypt. Many apps avoid the issue by using a hosted auth provider, social login or email magic links.
Sessions or tokens — which should my app use?
Both work. A session stores login state on the server and gives the browser a random ID in a cookie, which is easy to revoke. A token such as a JWT carries signed information itself, which suits APIs and mobile clients but is harder to cancel before it expires. For a typical web app, cookie-based sessions are a sound default.