Authentication is one of the topics where senior frontend engineers are expected to know more than the basics. Interviews increasingly probe for understanding of SAML for enterprise SSO, OIDC/OAuth for typical SaaS, passkeys for the post-password future, and the practical security pitfalls that show up in production. This guide covers what hiring managers want to hear.
The auth stack at a glance
- SAML 2.0: enterprise SSO; XML-based; old but dominant in B2B
- OIDC (OpenID Connect): JWT-based identity layer on OAuth 2.0; the modern default for consumer and SaaS
- OAuth 2.0: authorization (delegated access to resources)
- Passkeys (WebAuthn): the password-replacement standard; consumer adoption growing
- SCIM: not auth, but adjacent — user provisioning to your app from the IdP
SAML in 2026
- Still the default for enterprise IdPs (Okta, Azure AD, OneLogin)
- XML-based; assertion signatures are the security primitive
- Implementation: never roll your own; use a library or auth provider
- Frontend role: typically just kicks off the redirect to the IdP; the heavy lifting is server-side
OIDC for typical SaaS
The flow most engineers should know cold:
- Frontend redirects to /authorize endpoint with client_id, redirect_uri, scopes, PKCE challenge
- User logs in at the auth provider
- Provider redirects back with an authorization code
- Frontend exchanges code for tokens (PKCE verifier proves it is the same client)
- Returns: id_token (JWT), access_token, refresh_token
PKCE — the modern requirement
- Proof Key for Code Exchange — protects against authorization code interception
- Required for public clients (SPAs, mobile apps)
- Generate code_verifier (high-entropy random); send code_challenge (SHA256 hash) on /authorize
- Send code_verifier on /token
Where do tokens live?
The most-debated frontend auth question:
- HttpOnly cookies (sessions): safest; immune to XSS token theft; CSRF protection needed
- localStorage: convenient; vulnerable to XSS; not recommended for production
- sessionStorage: tab-scoped; same XSS risk as localStorage
- In-memory: safe but lost on refresh; pair with refresh-token-via-cookie
The 2026 best practice for SPAs: refresh token in HttpOnly cookie; access token in memory; refresh on demand.
Sessions vs JWTs
- Sessions: server stores state, client has only an opaque cookie; revocation is trivial
- JWTs: stateless; revocation requires a denylist or short expiry; suitable for distributed services
Most monolithic apps use sessions. Microservices and B2B platforms use JWTs.
Passkeys (WebAuthn) in 2026
The post-password future is here. Adoption:
- Apple, Google, Microsoft all support passkeys natively
- iOS 16+, Android 9+, modern browsers
- Cross-device passkey sync via iCloud Keychain / Google Password Manager
- Many SaaS apps offer passkey as an option alongside passwords
The flow
- Registration: server sends challenge; browser prompts user (biometric); device generates keypair; sends public key to server
- Login: server sends challenge; browser prompts user; device signs with private key; server verifies
- Private key never leaves the device
Multi-factor authentication
- TOTP via authenticator app (Google Authenticator, Authy)
- SMS — falling out of favor due to SIM-swap attacks
- WebAuthn / FIDO2 — strongest second factor, often combined as primary in passkey flows
- Push to authenticator app (Duo, Microsoft Authenticator) — convenient and secure
Single sign-on UX
- “Sign in with Google” buttons — OAuth flow
- Enterprise SSO — typically email-domain detection: type your email, redirect to your IdP
- “Magic link” via email — replaces password for low-stakes apps
The CSRF question
- Cookies sent automatically on cross-origin requests
- Mitigation: SameSite=Strict cookies, CSRF tokens, double-submit cookie
- Modern SameSite=Lax default in browsers reduces but does not eliminate the risk
The XSS-token-theft chain
- If your app has any XSS vulnerability, tokens in localStorage are stolen
- Defense: HttpOnly cookies for tokens; Content Security Policy; sanitize all user input
- Even framework-rendered apps can have XSS via user-provided URLs (javascript: protocol), HTML in props, etc.
OAuth scope minimization
- Request only what you need
- Users react badly to over-scoped requests; declines are frequent
- Incremental authorization: ask for read first; ask for write later if needed
What interviewers reward
- Naming OIDC vs OAuth correctly (OIDC is identity; OAuth is authorization)
- Discussing PKCE for SPAs and mobile apps
- Cookie-vs-localStorage tradeoff with XSS framing
- Mentioning passkeys as the modern direction
- Discussing SAML for enterprise customers (B2B SaaS)
- Refusing to roll your own auth — name a provider (Auth0, Clerk, WorkOS, Supabase)
Common interview questions
- “Walk me through the OIDC authorization-code flow with PKCE.”
- “Where would you store the access token in an SPA?”
- “How would you implement enterprise SSO for our B2B product?”
- “Implement a passkey registration flow.”
- “What is the threat model of putting tokens in localStorage?”
What separates senior from staff
Senior candidates know the major flows. Staff candidates discuss the threat model — XSS, CSRF, token-theft chains — and design defense-in-depth. Principal candidates raise the operational side (key rotation, refresh-token leakage, account-takeover protection) and the user-experience tradeoffs.
Frequently Asked Questions
Should I roll my own auth?
No. Auth0, Clerk, WorkOS, Supabase Auth, Firebase Auth — all are battle-tested. Mistakes in auth are catastrophic.
Are passkeys ready for production?
Yes for new apps. Adoption is fast. Offer alongside passwords for the next 1–2 years; passkey-only is risky if your user base is older or less technical.
How do I handle “Sign in with Apple” for app-store compliance?
If you offer Sign in with Google or Facebook on iOS, Apple requires offering Sign in with Apple too. Check current App Store policy; it has shifted.
Useful next steps:
