Signing in is your product’s first security promise. Passwords or passkeys, second factors or single sign-on, session length, recovery — these choices shape support load and trust, so settle them deliberately.
There is no single right login for every product: a small consumer app and a business tool sold to companies with their own identity systems face different risks. Answer four questions first: who signs in, what damage follows if the wrong person gets in, what friction users tolerate, and how a legitimate user recovers.
The controls those answers point to are not interchangeable. A second factor adds a separate proof at sign-in. Single sign-on moves where sign-in happens; it does not by itself make sign-in stronger — the provider’s methods and policies decide. For sensitive accounts, require appropriate MFA, directly or through an identity provider that enforces it. Match recovery to the account's assurance requirements.
A login screen serves more than one population. Self-serve customers sign up alone; a flow that asks a lot before they see value can lose some of them. Business customers may arrive through an administrator who expects leavers to lose access. Staff need separate, tightly controlled access to customer data. Write them down: creation, approvers, leavers, actions needing fresh proof. The SaaS development planning guide covers roles and permissions as a planning decision for the same reason.
NIST’s current standard, SP 800-63B-4, sets the shape: passwords used on their own should be at least 15 characters, at least 8 when they form part of multi-factor authentication, and systems should allow at least 64 so passphrases fit. OWASP’s Authentication Cheat Sheet gives the same direction in practitioner form. Screen new passwords against common and breached lists. Those figures bind systems inside NIST’s framework; here they are a benchmark, not a legal duty.
Drop two older habits. Do not require password changes on a fixed schedule: NIST’s position is that they should not be changed arbitrarily; a forced change should follow evidence of compromise. Do not use security questions as a way back in: NIST withdrew them because answers are often private but not secret; OWASP no longer recognises them as a factor. Let users paste passwords, so managers work.
Protect the login endpoint too: OWASP’s Authentication Cheat Sheet describes throttling and lockout as standard protections after repeated failures, but lockout needs balance, or legitimate users get locked out. Failure messages should stay generic — identical for a missing account, a wrong password, or a locked account. Our guide to SaaS data security basics covers the wider controls.
Multi-factor authentication means evidence from two distinct factors — something you know, something you have, something you are. Two pieces of one factor (password plus PIN) do not count; OWASP requires independence.
Authenticator apps generate time-based codes: a practical middle ground, though a code can be tricked out of a user into a fake page, and a lost phone without backup breaks the method. Hardware OTP tokens share the weakness: NIST notes OTP authentication is not phishing-resistant.
Codes by text message or voice call carry their own limits: OWASP, citing NIST, designates SMS and telephone codes as a restricted authenticator — interception, SIM-swap, and number-porting attacks — and advises against relying on them for sensitive data. Email codes have specific limits: they rest on the mailbox’s own security, which may be a password alone; the mailbox is exposed to phishing; and compromised mailbox access can undermine the extra check, as OWASP’s Multifactor Authentication Cheat Sheet explains. Using one device does not itself prevent MFA. NIST goes further within its own framework: SP 800-63B-4 does not permit email for out-of-band authentication, citing password-only mailbox access, interception, and rerouting — binding on systems inside that framework, not every SaaS product by law.
Push approvals carry a specific risk: attackers flood users with prompts hoping one is accepted — OWASP calls this MFA fatigue; number matching and prompt limits are the mitigations. FIDO/WebAuthn security keys bind authentication to the genuine site; they do not generate codes for users to type into a fake page. Budget for buying, distributing and replacing physical keys; decide which users need them based on risk and support needs.
A passkey replaces the typed password with a key pair: the private key stays with the user’s device or credential manager; you keep only the public key. Signing in is a challenge and response — your service sends a challenge, the device answers with the private key, after the local check (PIN or biometric) where user verification is required, as NIST's authenticator guidance walks through. An already-unlocked device does not by itself answer each request. Bound to your domain, it will not work on a fake login page.
That local check can make a passkey multi-factor on its own: the device or synced credential (something you have) plus a PIN or biometric check (something you know or are). Where user verification is required and validated, passkey sign-in is itself multi-factor authentication — no separate password or code is inherently necessary. The NCSC’s passkeys assessment agrees, treating FIDO2 credentials with user verification as MFA.
Losing a phone is not the same as losing every credential. Synchronised passkeys copy through the user’s credential manager, so a replacement device on the same account can usually restore them; a device-bound passkey does not travel. The serious cases — losing every usable credential, or access to the passkey provider account itself — need explicit plans. Synchronisation works within the provider’s system; moving ecosystems takes extra steps. Plan the management screen early: see and remove passkeys, plus a tested route back in for total loss.
Single sign-on (SSO) lets users sign in once, at an identity provider, across applications. For business customers it is often required. But SSO centralises authentication rather than strengthening it — sign-in is only as strong as the provider’s methods and policies, such as whether it enforces a second factor. Agree what identity information you receive and how leavers are handled.
Removing a leaver needs care. Disabling their account at the provider stops new sign-ins there, but does not automatically terminate sessions already open in your application, and issued tokens may still run. Agree and test the whole path: deactivation, live sessions, tokens, and how quickly access is gone.
“Sign in with” buttons are lighter: faster signup, no new password. The trade is dependence: where the provider is one route among several, keep a recovery route independent of it; where a business customer enforces SSO, do not offer an alternative login that bypasses their policy — recovery runs through their administrator. OWASP warns against linking a federated identity merely because the email matches: addresses are not guaranteed unique or stable. Linking should prove control of both sides — the existing account and the new identity — and for OpenID Connect the account is identified by issuer plus subject identifier, as the OpenID Connect Core specification defines.
Three names recur, and confusing them causes scope errors. OAuth 2.0 (RFC 6749) is an authorisation framework: it lets a user grant an application limited access on their behalf, without handing over a password; it does not by itself prove who the user is. OpenID Connect (OIDC) adds that identity layer: the OpenID Connect Core specification describes a simple identity layer on OAuth whose ID token carries verified claims, which your application validates before creating a session.
OASIS — SAML V2.0 (2005; accessed 30 October 2026).
SAML (Security Assertion Markup Language) is an XML-based standard used for enterprise sign-on. Choose SAML or OIDC according to customer systems and integration needs; OAuth handles delegated API access. Supporting more than one is a scope decision to price.
Signing in creates a session, standing in for the login afterwards. Sessions need two different time limits, as OWASP’s Session Management Cheat Sheet sets out: an inactivity timeout, ending a session left unused for a set period, and a maximum duration, ending even an active session after a set total time. Choose both for your product’s risk and use. Logout must invalidate the session on the server, not merely hide it in the browser.
Session handling after a password change depends on why it changed: a routine change by a re-authenticated user is one case; a reset after a forgotten password, or any sign of compromise, is another — there, ending other sessions is the safer default. Sensitive actions deserve a fresh check: OWASP recommends requiring current credentials before changing a password or email address, or before a sensitive transaction — the same principle the payments guide applies to payments.
Recovery deserves risk-based design. It need not mirror login exactly, but it must meet the account’s assurance needs without becoming an easier way in. Distinguish changing a factor while another remains — requiring re-authentication, with notification through another channel — from recovering when every factor is lost, which needs your strongest process. OWASP suggests single-use recovery codes issued at setup, a second enrolled factor so one loss is not fatal, and a support process with rigorous checks where no self-serve route exists. Test the unhappy paths first.
It depends on your audience — a decision to test, not a slogan. Check device and browser support, accessible enrolment, and whether backup credentials and recovery hold up. Keeping passwords alongside passkeys is one option, but not a requirement — and any fallback needs protection of its own, since attackers try the weakest door.
No — delegated, not settled. The provider handles the mechanics you configure; you still own who signs in, the factors required, how accounts link, and how recovery works. Ask a trial to demonstrate each.
OWASP — Authentication Cheat Sheet (accessed 30 October 2026).
OWASP — Multifactor Authentication Cheat Sheet (accessed 30 October 2026).
OWASP — Session Management Cheat Sheet (accessed 30 October 2026).
NIST — SP 800-63B-4 (2025; accessed 30 October 2026).
NCSC — Passkeys are more secure than traditional ways to log in (published 23 April 2026, updated 28 May 2026; accessed 30 October 2026).
Google — Passkeys use cases (accessed 30 October 2026).
OpenID Foundation — OpenID Connect Core 1.0 (errata set 2; accessed 30 October 2026).
IETF — RFC 6749: The OAuth 2.0 Authorization Framework (2012; accessed 30 October 2026).
If you are scoping a SaaS product, the project cost calculator gives an indicative cost and timeline from scope and complexity. Authentication and account management are part of iCodeLTD’s SaaS development service. To talk through your decisions, use the contact page.
AI Solutions
Is Your Business Data Ready for AI? A Founder's Guide to Preparing Data Before an AI Project
Before you choose an AI tool or start a build, check whether your data can be found, understood, trusted, and lawfully used for the decision in hand.
Read moreSaaS Development
Adding Payments to Your SaaS or Web App: What Founders Should Decide Before the Build
What founders should decide before adding payments: billing model, hosted or embedded checkout, PCI scope, authentication, failed payments, refunds and webhook handling.
Read moreProduct Delivery
Should You Test Before You Build? A Founder's Guide to Prototypes, Proofs of Concept and Pilots
Prototypes, proofs of concept, pilots and first releases each settle a different unknown. Learn which test your build decision actually needs, and what to agree before it starts.
Read moreReady to review scope for AI, SaaS, web, mobile, or automation work?
