# Frontend Authentication 2026: SAML, OIDC, OAuth, and Passkeys

Source: https://www.techinterview.org/post/3233475372/frontend-authentication-2026-saml-oidc-oauth-passkeys/
Updated: 2026-06-30 · techinterview.org

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.