In an SPA (react/ angular )Api calls go directly from browser, does it mean the the app cannot store variables that allows it third party oAuth providers like Google.

What works vs. what doesn’t

• No client secrets in the browser. A static SPA is a public client. Anything you embed can be read/abused.
• Use OAuth 2.1 Authorization Code + PKCE (not Implicit). The SPA talks to the Identity Provider (Google/Auth0/Cognito hosted UI), gets an auth code, exchanges it (with PKCE) for tokens.
• Federation is fine. Google, GitHub, etc. all support PKCE for public clients.

Token storage: do it safely

Backend-for-Frontend (BFF) — recommendation for production

Spin up a tiny backend (Lambda + API Gateway works great) on your domain.

• Flow: SPA → your BFF starts Google login → Google redirects back → BFF does the code exchange server-side and sets httpOnly, Secure, SameSite cookies.
• SPA never sees tokens. It just calls your API (/api/* same-site), cookies flow automatically.
• No CORS pain if you keep the app and API on the same site (e.g., app.example.com and api.example.com are “same-site” for cookies).
• Refresh tokens live server-side; BFF rotates access tokens and injects them to upstream APIs.

Pros: hardest to steal tokens, cleaner CORS, easier policy/rotation.

Cons: you run a small backend.

So, can you “store variables for OAuth”?

• Yes, you can store state, code_verifier (PKCE), nonce temporarily in memory/sessionStorage during the login round-trip.
• You cannot store or protect a client secret in the SPA.
• For persistent auth, prefer the BFF cookie approach. In pure SPA, rely on short-lived access tokens, renew as needed.

Practical checklist (React + S3/CloudFront)

• Serve the SPA from S3 (private) behind CloudFront. Add a rewrite to /index.html for client routes.