Authentication for BYOC apps
Your SaaS uses a hosted auth provider: Auth0, Clerk, WorkOS, or something like them. One application, one callback URL, one tenant, one dashboard where all your users live. It works so well you stopped thinking about it.
Then a customer asks you to deploy into their cloud, and two questions come up in the first architecture call:
- Where do API keys and user records live — your cloud or the customer's?
- How does a deployment in the customer's cloud authenticate back to yours?
Almost nobody plans for this. Auth is usually discovered mid-deployment, when the login redirect fails inside the customer's network. This post is the answer we give, and then the two alternatives for stricter environments.
Auth stays in the control plane
Auth stays entirely in your cloud. That is the point of the control-plane/data-plane split: identity is vendor state, not customer data, so it lives on the side you operate.
- User records, sessions, and API keys live in your control plane. Nothing identity-related is copied into the customer's account.
- The data plane holds no auth state. It verifies short-lived tokens issued by your control plane, or checks an API key against it. That's all.
- There are no per-customer auth callbacks. The customer's deployment never registers redirect URLs, never holds client secrets for your auth provider, never runs a login box.
Sequence diagram. Lanes: Control plane (your cloud), Browser (your user), Data plane (customer's cloud). Steps: 1 · sign in; 2 · short-lived JWT; 3 · request + JWT; 4 · verify JWT locally.
Walking through it: the user signs in against your control plane — your existing hosted auth, unchanged, with enterprise SSO federating there too (1). The control plane issues a short-lived JWT scoped to that deployment — minutes of validity, not days (2). The browser calls the data plane directly with that token (3).
Step 4 is what makes this scale: the data plane verifies the token's signature, locally, using the control plane's public key. The public key isn't a secret — it ships with the deployment like any other config. So there is nothing to call back to on the request path, nothing stateful to operate, and revocation is the tokens expiring in minutes.
How code calls it
The browser flow above covers humans using your dashboard. Programmatic access (a customer's service using your SDK) is simpler:
- 1
The SDK sends the API key straight to the data planecustomer cloud
No detour through your cloud. The request, and the data it touches, stay inside the customer environment.
- 2
The data plane verifies the key against the control planeoutbound
One outbound HTTPS call, cached with a short TTL, so revocation still propagates in seconds without a round trip per request.
Notice what's absent: no identity server in the customer's account, no secrets to distribute per deployment, no callback URLs to keep in sync as deployments come and go.
What breaks if you copy auth into each deployment
The instinct to run login inside every customer environment sounds isolated and safe. In practice it multiplies everything:
Callback URLs multiply. OAuth redirects the user back to a registered URL. In SaaS there is one. Per-deployment login means one per customer, often on internal domains, each registered with the provider and kept in sync as deployments come and go.
Secrets and tenants multiply. Client secrets and signing keys now need to exist inside each customer environment: delivered encrypted, rotated without a redeploy, and invisible in the artifacts customers inspect. And where hosted auth modeled all your customers inside one application, you now run one auth tenant per customer — or one shared tenant that mixes every customer's identity data, which many will reject on sight. Everything that used to be one thing becomes N things.
Licensing costs multiply. Hosted auth pricing scales with tenants and enterprise SSO connections. Per-deployment tenants times per-connection fees turns a rounding error into real COGS on exactly the deals BYOC exists to win.
The two stricter patterns
Control-plane auth assumes the customer accepts one thing: login traffic and identity metadata (not data) touch your infrastructure. Most do. For those that don't, there are two fallbacks.
Per-deployment IdP configuration. The deployed app speaks OIDC or SAML directly to the customer's Okta or Entra. Login never leaves their network. Enterprises like it because it matches how they onboard any internal app: their IdP team creates a registration and hands you the values. The cost is yours: N configurations to collect, store, and rotate, and IdP misconfiguration becomes a support category.
Self-contained auth in the data plane. For fully private and air-gapped environments, login has to happen locally. Resist the instinct to ship Keycloak or Dex — a stateful, security-critical identity server you now patch in every customer account. An embedded auth library inside your app (better-auth or your framework's equivalent) gets the same "login never leaves their network" property with a fraction of the moving parts.
Comparison. Control-plane auth: One auth stack — yes; Login stays inside — no. Per-deployment IdP: One auth stack — no; Login stays inside — yes. Self-contained auth: One auth stack — no; Login stays inside — yes.
If the environment can make a single outbound HTTPS call to your control plane, use control-plane auth and don't run identity in the data plane at all. The fallbacks exist for environments that can't.
Where Alien fits
Alien is built around the control-plane/data-plane split, so "auth lives in the control plane, the data plane verifies a token" is the default, not something you engineer. Identity is stateful, security-critical logic — it belongs on the side you operate and update continuously, not copied into a hundred environments you can't reach.
For the fallback patterns, where some configuration genuinely lives in each environment (an IdP issuer, client ID, client secret), those are per-deployment inputs: typed, validated, encrypted where they're secret, and collected at setup through the portal or CLI instead of emailed afterward.
The IdP handshake itself is always between your product and your customer's identity team; anyone claiming a deployment tool does that part for you is describing a demo. What a platform can do is make the sane default cheap — and the sane default is that identity never leaves your side of the boundary.
The deployment model this all sits on is in what is BYOC?, and the component most teams already run in customer environments without an auth story at all is in the agent nobody operates.