Module 2 — Tenant Building Blocks

Learning objectives

Name the four core resources of a tenant and how they relate.

Explain how Faable resolves which tenant a request belongs to.

Know where each resource lives in the dashboard.

Four concepts model the whole product

From the Get Started guide:

Account — your auth tenant. Hosted at https://<account>.auth.faable.link or under your own custom domain. Everything below hangs off the account.
Connections — sources of users: database (email + password), social (Google, GitHub, Apple…), passwordless, or generic OIDC/SAML.
Clients — the applications that drive an OAuth flow against your account. Each has a Client ID, optional Client Secret, and Allowed Callback URLs.
Users & Teams — identities created through your connections, optionally grouped into teams with RBAC (roles + role members).


Account (tenant)
├── Connections        (how users authenticate)
├── Clients            (which apps can ask)
├── Users / Identities (who has authenticated)
└── Teams / Roles      (how users are grouped & authorized)

How a tenant is resolved: by host

Faable Auth is multi-tenant. The tenant is determined from the host of the incoming request: acme.auth.faable.link → the acme account; a custom domain like login.acme.com → whichever account claims it. Each account has its own keystore, clients, connections and users — they are fully isolated.

As an integrator you rarely set this yourself: you point the SDK at your tenant’s domain and Faable does the rest. Just remember that the domain identifies the tenant, which is why the SDK always needs a domain.

Clients in a bit more depth

A client represents one application. Two things matter most when integrating:

Public vs confidential. A browser/mobile app is public — it cannot keep a secret, so it uses PKCE instead (Module 3). A backend is confidential and uses a client secret.
Allowed Callback URLs. After login, Faable will only redirect back to URLs you have explicitly allow-listed. A mismatch here is the #1 “it works locally but not in prod” bug — add every environment’s callback URL.

See Clients for the full field reference.

Connections in a bit more depth

A connection is a way to authenticate. You can enable several at once; the login screen shows the ones enabled for that client. Connections can be restricted to specific clients (enabled_clients). Types include:

Database — email + password, with a configurable password policy.
Social — Google, GitHub, Apple, Facebook, etc. (see Social).
Passwordless — magic link / OTP (Passwordless).
OIDC / Enterprise — federate to another identity provider.

Check yourself

You have a Next.js web app and a separate mobile app hitting the same tenant. How many clients do you create, and are they public or confidential?
A teammate says “login redirects to a Faable error page after the user signs in.” What’s the first thing you check?
Where does a user come from — you create them manually, or…?

Answers

Two clients, both public (they run on the user’s device and can’t hold a secret) → both use PKCE.
The Allowed Callback URLs on that client — the post-login redirect_uri must be allow-listed exactly.
Users are created through a connection when they authenticate (or via invitations / admin APIs). The connection is the source of users.

Next: Module 3 — Login & Flows.