PS Product SecurityKnowledge Base

🔑 OAuth for SPA, BFF, and Frontend Secret Anti-Patterns

Intro: Frontend identity choices should be evaluated by how much authority they expose to the browser, how replayable the tokens are, and how cleanly they support logout, session rotation, and downstream authorization.

What this page includes

  • when SPA-only flows are acceptable
  • why the BFF pattern often simplifies risk
  • common mistakes with tokens and browser storage
  • how to review frontend auth designs

SPA versus BFF

A pure SPA can be workable, but a Backend-for-Frontend often makes the security model easier because it moves token handling and upstream calls out of the browser and back into a server-controlled trust boundary.

Anti-patterns

  • frontend bundles containing secrets or long-lived API credentials;
  • access tokens stored broadly in browser storage without a good reason;
  • confusing authentication with authorization and pushing too much trust into frontend checks;
  • incomplete logout that leaves long-lived session artifacts behind.

Review questions

  • Which tokens exist in the browser, and why?
  • Can the browser directly call privileged upstream APIs, or only the BFF?
  • How are session renewal, device loss, and risk events handled?
  • Does the frontend reveal roles, entitlements, or feature flags that should remain server-authoritative?

Prefer server-held sessions or BFF-mediated access for high-value products, especially when the product handles tenant data, admin workflows, or regulated information.

Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.