← Integration guides

Web frontend + your own backend (BFF)

Your frontend never talks to this platform. Not React, not Vue, not Svelte, not Angular, not plain JS — whichever you use, the actual OAuth work (PKCE, the redirect, the code-for-token exchange) belongs entirely to your own backend — see the Django, Node.js, Laravel, or Go guide for that half. This is why there's one page here, not five — the frontend's own job in this pattern is small and identical regardless of framework.

What your frontend actually does

  1. Renders a login link — a plain <a>, pointing at your own backend's login route (e.g. /auth/login), never at accounts.onehux.com directly.
  2. Your backend handles everything from there — the PKCE pair, the redirect to this platform, the callback, the token exchange — and finishes by setting its own session (a cookie your frontend's own domain controls).
  3. Your frontend calls your own backend's API for user data (e.g. GET /api/me), which your backend fills in by calling this platform's /api/v1/oauth/userinfo/ server-side — your frontend never holds, sees, or handles a OneHux access token at all.

Why — the token never belongs in the browser

A token held in localStorage, a JS variable, or any client-JS-reachable state is one XSS bug away from being exfiltrated — there is no way to make client-side JS hold a bearer credential safely. An httpOnly cookie set by your own backend is unreadable by any JS at all, on either side, which is the entire point. This is the exact pattern this dashboard you're reading right now uses on itself — not a theoretical recommendation, a real, currently-running example of it.

Example — a login link and an authenticated fetch

<!-- Any framework — this is the entire frontend-side surface of this integration -->
<a href="/auth/login">Sign in</a>
// Your frontend calling YOUR OWN backend — never OneHux directly
const res = await fetch('/api/me', { credentials: 'include' });
const user = await res.json(); // whatever shape your own backend chooses to return

If your frontend framework has its own server layer

A meta-framework with its own server runtime (SvelteKit, Next.js, Nuxt, Remix) can play the "backend" role itself — that server-side half (its load functions/API routes/server actions) follows exactly the same pattern as the Node.js guide, just inside the meta-framework's own server runtime instead of a separate Express app. The client-side half — the part actually running in the browser — is still exactly what this page describes: it never touches a token, never calls this platform directly.

← React Native