You usually notice authentication only when it breaks. The login spinner hangs, the password reset email never arrives, the magic link opens on the wrong device, or your SPA works fine in staging and then turns into a token handling mess in production. Authentication sits in that annoying category of engineering work that looks simple in demos and gets expensive the moment you add real users, multiple devices, social login, admin actions, and a security review.
In plain language, a secure authentication flow is the sequence of steps your app uses to prove who a user is, keep that proof alive safely, and challenge them again when the risk changes. For a modern web app, that usually means some mix of passwords or passkeys, session cookies, MFA, OAuth or OpenID Connect, careful token handling, and recovery flows that do not become the attacker’s favorite shortcut. The trick is not choosing the fanciest protocol. The trick is choosing the boring, defensible path that survives XSS, CSRF, phishing, token leakage, and account recovery edge cases.
Our research turned up a pretty consistent pattern. Alper Kerman, security engineer and project manager at NIST’s NCCoE, has been involved in work that treats passkeys as a practical route to phishing-resistant, secure authentication for many mainstream use cases, especially when implemented with the right lifecycle and recovery controls. Aaron Parecki, security architect at Okta and a contributor to browser-based OAuth guidance, has spent years pushing the industry away from implicit flow and toward Authorization Code with PKCE for browser apps because browser code cannot keep a client secret and should not be trusted to handle long-lived credentials casually. The OWASP cheat sheet authors, writing from the trenches rather than a standards committee podium, keep making the same point in plainer language: rotate sessions, reauthenticate on risky actions, and treat storage, recovery, and cookies as part of auth, not as afterthoughts. Put together, the message is refreshing and a little humbling. The secure auth flow is usually not the clever one. It is the one with fewer places to leak secrets and fewer chances to confuse users into insecure recovery behavior.
Start with the right flow, not the right library
Most teams begin by asking which auth vendor or framework to use. That matters, but the more important first question is what trust boundary you are designing for. A server-rendered app that mainly talks to its own backend should usually prefer server-side sessions in secure cookies. A browser-heavy app that talks to APIs still benefits from a backend-for-frontend, often called a BFF, so the browser handles less token material. If you also need third-party identity, add OpenID Connect on top of OAuth, but keep the browser’s job small.
Here is the decision most teams actually need to make:
| App shape | Best default | Why is it safer |
|---|---|---|
| Server-rendered app | Server session cookie | Minimal token exposure in the browser |
| SPA with your own API | SPA plus BFF | Keeps sensitive tokens off the frontend |
| App with Google, Microsoft, and Okta login | OIDC with Authorization Code + PKCE | Standardized federation with safer browser flow |
That table looks almost too tidy, but it captures a hard-earned lesson. You want the browser to present proof, not to become your long-term secrets vault. This is why teams that store long-lived access or refresh tokens in localStorage often end up one XSS bug away from a security incident and a very long week.
Passkeys are the strongest default for sign-in, but you still need a password story
If you can support passkeys, support passkeys. They are one of the clearest improvements modern web apps can make because they replace reusable shared secrets with scoped public key credentials. That is a big deal. Attackers cannot replay what they never steal.
That said, most products are not living in a pure passkey future yet. You still need to design for users who arrive with nothing but an email address and a memory that may or may not be reliable after two coffees and a weekend. For those users, store passwords with modern password hashing, not with a fast general-purpose hash. Recovery is equally important. Use consistent responses to avoid user enumeration, secure random single-use reset tokens, and side-channel delivery such as email or another out-of-band method.
A practical rollout looks like this. Let users sign up with passkeys where available, offer password plus MFA as a fallback, and prompt existing password users to add a passkey after a successful sign-in. That gives you a path to stronger auth without turning day one onboarding into a support ticket factory. The security win is not just a stronger login. It is a smaller phishing surface over time.
The session is where good authentication goes to die
A login can be flawless and still be undermined by sloppy session handling. After secure authentication, you need a session identifier that is unpredictable, rotated when privilege changes, invalidated on logout, and protected in transit and in the browser. Cookie-based sessions remain a very strong default for web apps because they let the server stay in control.
This is the place where a lot of modern frontend teams get tempted by convenience. localStorage feels simple because you can inspect it, ship fast, and attach a bearer token on every request. Unfortunately, the same persistence and accessibility that make it convenient also make it attractive when XSS happens. That does not mean localStorage is evil. It means you should store low-risk client state there, not the crown jewels.
A concrete example helps. Suppose your app sees 500,000 authenticated API requests per day, and your average user makes 25 requests per session. That is roughly 20,000 sessions daily. If a session rotation bug leaves only 0.2% of sessions reusing an old session ID after privilege elevation, that is about 40 potentially exposed sessions every day. It does not sound cinematic, but that is the math of real incidents. Auth failures at tiny rates become operational problems at scale.
Build the flow in layers: login, verification, reauthentication, recovery
The biggest design mistake I see is treating secure authentication like a single screen. In reality, you need at least four connected flows: initial sign-in, step-up verification, recovery, and session termination. This matters because “logged in” is not the same as “safe to wire money” or “safe to transfer account ownership.”
Here is how to implement that without making users hate you. First, authenticate the user with a passkey or password plus MFA. Second, issue a hardened session cookie and record device and risk signals server-side. Third, require step-up, secure authentication before high-impact actions like changing MFA methods, adding an admin role, exporting sensitive data, or changing payout details. Fourth, keep recovery completely separate from the main login state. Password reset and MFA reset are attacker magnets, so they should use single-use tokens, short expiries, out-of-band delivery, uniform responses, and notifications after sensitive changes.
Here is how that looks in practice.
- User enters email and chooses passkey or password.
- Server authenticates and issues a secure session cookie.
- High-risk actions trigger step-up verification.
- Recovery uses one-time reset tokens sent out-of-band.
- Sensitive changes notify the user and rotate sessions.
That list is short on purpose. The flow should be easy to explain to your own engineers at a whiteboard. If you need a 30-minute meeting to describe it, your attackers will appreciate the extra complexity more than your users will.
Protect the browser side like it is hostile territory
Modern browsers are powerful, but your app still runs inside an environment full of extensions, injected scripts, third-party packages, and mistakes. That is why browser-side auth should aim for damage containment. The browser should have just enough information to continue the flow, not enough to mint trust forever.
CSRF also has not gone away just because everyone has a framework now. That means cookie-based sessions should pair restrictive cookie settings with CSRF protections on state-changing requests, especially if business needs force SameSite=Lax rather than Strict.
This is also where architecture pays dividends. A BFF pattern can exchange OAuth codes server-side, keep refresh tokens off the frontend, and issue only a first-party session cookie to the browser. That is not trendy. It is just effective. You give up a little frontend purity and gain a lot of sleep.
A secure implementation plan for most teams
If you are building a modern SaaS app today, this is the setup I would recommend unless you have unusual constraints. Use OIDC with Authorization Code plus PKCE for external identity. Use a BFF or traditional backend session layer so the browser mainly holds a secure, HttpOnly, Secure, preferably a host-prefixed cookie. Offer passkeys first, keep password plus MFA as a fallback, and hash passwords with a modern password hasher. Add reauthentication for sensitive actions. Treat recovery as a first-class security flow with one-time tokens, uniform responses, and user notifications. Rotate sessions after password reset, MFA enrollment changes, and privilege elevation. Log auth events server-side with enough detail to investigate abuse without storing secrets.
If you need a litmus test, ask this: “If my frontend bundle and browser storage were fully visible to an attacker, how much lasting trust would they gain?” Your goal is “not much.” If the answer is “they get refresh tokens, a privileged JWT, and enough context to reset MFA,” you do not have a secure authentication flow. You have an incident waiting for good Wi-Fi.
FAQ
Should I store JWTs in localStorage?
Not for sensitive long-lived auth state if you can avoid it. A first-party secure cookie is usually the safer default for web apps.
Are passkeys enough, or do I still need MFA?
Passkeys are already a strong, phishing-resistant factor in many cases. But you still need step-up policies, recovery controls, and careful enrollment for high-risk accounts. Strong sign-in does not eliminate lifecycle risk.
Is SameSite=Lax enough CSRF protection?
No. It helps, but it is only a partial defense. Use anti-CSRF tokens and verify intent on state-changing actions.
Do SPAs have to use a BFF?
Not always, but many should. A BFF reduces token exposure and usually simplifies your threat model.
Honest Takeaway
Secure authentication flows are less about adding more steps and more about putting trust in the right place. The modern default is pretty clear: passkeys where you can, password plus MFA where you must, Authorization Code with PKCE for browser-based OAuth, and server-controlled sessions rather than treating the browser like a secure wallet. None of that is glamorous. All of it works.
The real work is in the edges. Recovery, reauthentication, cookie policy, session rotation, and token handling are where mature teams separate themselves from slide-deck security. If you get those right, your auth flow stops being a collection of screens and becomes what it should have been all along, a security boundary your product can actually rely on.
Rashan is a seasoned technology journalist and visionary leader serving as the Editor-in-Chief of DevX.com, a leading online publication focused on software development, programming languages, and emerging technologies. With his deep expertise in the tech industry and her passion for empowering developers, Rashan has transformed DevX.com into a vibrant hub of knowledge and innovation. Reach out to Rashan at [email protected]
