What is email & password login?
Email and password login is the most common way users authenticate with an app. A user registers with their email address and a password, and returns with the same credentials on subsequent visits. Simple in concept, but there are several pieces that must be implemented correctly — getting any one of them wrong creates security vulnerabilities.
Done properly, this includes: password hashing (never storing passwords in plain text), email verification to confirm the address is real, session management with JWTs or server-side sessions, a password reset flow via a time-limited email link, and optionally a "remember me" toggle that extends session lifetime.
This is typically the first auth feature built, and most others — two-factor authentication, social login, SSO — layer on top of it.
When does your app need it?
- You need a private area of your app that requires users to identify themselves
- You're building a web or mobile app with user-specific data (orders, settings, history)
- Your users are unlikely to have a Google or Apple account, or prefer not to use social login
- You need a fallback auth method even if you also offer social login or SSO
- You're building for a sector (healthcare, government, finance) where password-based auth with MFA is a compliance requirement
- You want full control over the user database and auth flow without depending on a third-party identity provider
How much does it cost?
Adding email and password login typically adds 3–5 hours of development — roughly from $1,000 AUD.
At the lower end: a straightforward implementation using a managed auth provider like Supabase Auth, Clerk, or Auth0 handles most of the complexity (hashing, sessions, email delivery) and cuts build time significantly.
At the higher end: rolling your own with bcrypt or Argon2 for password hashing, custom JWT issuance and refresh token rotation, and a fully branded email verification and password reset flow adds time but gives you complete ownership of the auth stack.
How it's typically built
Passwords are hashed using bcrypt or Argon2 before storage — the original password is never saved. On login, the submitted password is hashed and compared to the stored hash.
Sessions are managed with JWTs: a short-lived access token (15–60 minutes) and a longer-lived refresh token stored in an HTTP-only cookie. The refresh token is rotated on each use to detect theft.
Password resets use a time-limited, single-use token emailed to the user — typically a signed URL valid for 1 hour. Email verification at signup uses the same pattern.
Managed providers (Supabase Auth, Clerk, Auth0) handle all of this out of the box and reduce build time to wiring up the UI. Rolling your own gives full control and no per-user pricing.
Questions to ask your developer
- Are passwords hashed with bcrypt or Argon2? MD5 or SHA1 are not acceptable for password storage — ensure a purpose-built password hashing algorithm is used.
- How are sessions handled? JWTs with short expiry and refresh token rotation, or server-side sessions? Each has trade-offs around scalability and revocation.
- Is email verification enforced before login? Skipping this allows bots to register with fake addresses and can cause deliverability issues.
- What's the password reset flow? Tokens should be time-limited, single-use, and invalidated after the password is changed.
- Are you using a managed auth provider or rolling your own? Managed providers reduce build time and ongoing maintenance burden; custom builds offer more control.
See also: Social login · Two-factor authentication · Enterprise SSO · App cost calculator