Passwordless authentication with a BFF: keep sessions out of browser JavaScript
Passwordless sign-in can be both low-friction and robust when the browser never handles the session directly. Here is a practical BFF pattern, its limits and the decisions that matter.
Nishmika Ekanayaka
Passwordless authentication is not automatically safer than passwords. The useful security boundary is where the session lives. A backend-for-frontend (BFF) keeps the browser focused on the interface while the server exchanges, refreshes and protects the session.
This pattern suits products with sensitive data, several user roles or more than one web application. It draws on lessons from building a real-world platform, including Drivio, but the implementation below is deliberately generic. No product-specific routes, identifiers or security controls are disclosed.
Key takeaways
- Use email codes, magic links or passkeys to prove identity, then keep the session in a Secure, HttpOnly cookie. Browser JavaScript should not need to read a refresh token.
- Make the BFF the only browser-facing auth client. It centralises session refresh, CSRF checks, redirect validation and audit logging.
- Keep authentication and authorisation separate. A valid session says who someone is. Your API or database must still decide what they may do.
- Treat shared parent-domain cookies with care. A cookie sent to sibling hosts needs a deliberate domain and key-management strategy.
Passwordless sign-in removes one problem, not every problem
A one-time code or magic link means the product does not have to store, reset or defend a reusable password. It does not eliminate phishing, inbox compromise or automated guessing. Rate limits, short expiry, attempt limits and a clear recovery route remain part of the design.
For browser-based OAuth clients, the IETF describes a BFF as one of the recommended architectures because it can keep tokens away from the browser and use a secure, HttpOnly cookie between browser and backend. Read the OAuth guidance for browser-based applications before choosing an architecture, especially where the product uses third-party identity providers.
The BFF pattern in plain English
The result is a useful division of labour. The browser sends a request to its own backend. The backend deals with the identity provider and returns only the rendered page or API response. This is not security by obscurity. It is reducing how many places can accidentally expose a session.
Set cookie attributes deliberately
An HttpOnly cookie prevents page JavaScript from reading it. A Secure cookie is sent only over HTTPS. SameSite changes when it accompanies cross-site requests. These are distinct controls, and the OWASP session-management guidance explains their role and limits.
Use the smallest practical cookie scope. A host-only cookie is usually simpler and safer than a parent-domain cookie. If single sign-on genuinely needs a shared domain, ensure every receiving host is trusted, use different secrets per environment, and include enough environment context to reject a cookie issued elsewhere.
Make safe mutations the default
Every state-changing endpoint should follow one well-tested route shape: accept only the content types it expects, verify the request origin or CSRF token, read the session server-side, enforce authorisation, return non-cacheable private data and log the event without secrets.
SameSite is helpful but should not be the whole CSRF strategy. Sibling subdomains are considered same-site, which is why OWASP recommends treating same-site requests cautiously when not every sibling host is fully trusted. See its CSRF prevention guidance on same-site subdomains and Origin checks.
Keep authorisation where the data is
A BFF can make session handling safer and easier to reason about. It should not become a second, drifting permission system. The API and database still need to check who may read or change each resource. Next.js makes the same distinction: authentication establishes identity, session management tracks state and authorisation decides access.
That distinction also makes code review sharper. A reviewer can ask whether a route correctly establishes identity, then separately ask whether the underlying operation is allowed. One successful email-code check should never become an implied permission to view a different customer, tenant or role.
A practical implementation checklist
- Choose the sign-in proof. Use a managed passwordless provider or passkeys rather than designing a token protocol from scratch.
- Put the provider exchange on the server. The browser should call your BFF, not receive refresh credentials directly.
- Set short, bounded session lifetimes. Rotate and revoke according to the provider and your risk model.
- Standardise mutation handling. Origin validation, input validation, authorisation and safe error mapping belong in one shared layer.
- Test the failure cases. Expired codes, replayed links, an invalid redirect, a missing secret and a revoked session should each fail safely and clearly.
Build the boring parts once
The value of a BFF is not a clever login screen. It is making the safe route the easy route for every feature that follows. Passwordless sign-in then becomes a calm entry point to a product whose real permissions are still enforced exactly where they belong.
Passwordless authentication FAQs
Is passwordless authentication enough on its own?
No. It proves control of a sign-in factor but still needs rate limiting, session protection, safe recovery and server-side authorisation.
Does HttpOnly remove the need for CSRF protection?
No. HttpOnly prevents JavaScript from reading the cookie. Browsers can still attach cookies to requests, so state-changing endpoints need CSRF defences.
When should a product use a BFF?
It is especially useful when a browser app handles sensitive data, needs multiple frontends to share an auth pattern or wants to keep identity-provider credentials out of browser JavaScript.
Ready when you are