Quickstarts
Pick your stack and wire up login, sessions and protected routes. Every frontend quickstart drives the same Authorization Code flow with PKCE through @faable/auth-js — the differences are only in how each framework handles reactivity and routing.
Frontend
| Framework | Use it when |
|---|---|
| React (SPA) | A client-side React app (Vite, CRA) with no server of its own. |
| Next.js | App Router with client components driving the session. |
| Next.js (Server-Side) | You need the session in Server Components, Route Handlers or middleware. |
| Vue | A Vue 3 SPA. |
| Nuxt | Nuxt 3, with the session available on the server side too. |
| SvelteKit | SvelteKit, load functions included. |
| Angular | Angular with a route guard and an HTTP interceptor. |
| JavaScript (Vanilla) | No framework — the framework-agnostic core pattern the others build on. |
| React Native | Mobile, using the system browser and a deep-link callback. |
Backend
| Stack | Use it when |
|---|---|
| FastAPI (Python) | Your API receives a Bearer token and must verify it — signature, issuer, audience and scopes. |
For Node.js the equivalent walkthrough lives in Validate Access Tokens, with an Express middleware. Any language works: the four checks are the same, and every stack has a JWKS-aware JWT library.
Before you start
Whichever you pick, you need a Client registered in the Faable Dashboard with:
- Allowed Callback URLs — where Faable redirects after login (e.g.
http://localhost:5173/callback). - Allowed Logout URLs — where users land after signing out.
- Allowed Web Origins — the origins allowed to call the token endpoint from a browser.
Plus your auth domain (your-domain.auth.faable.link, or your custom domain) and the Client ID. Frontend clients are public — no client secret is involved.
Related
- Get Started — the concepts behind the code: accounts, connections, clients, users.
- Authorization Code Flow — what these SDKs do under the hood.
- Social Login — let users sign in with Google, GitHub or Microsoft.
Last updated on