Sign in with Basable: a login for your app, with no setup

13 November 2026 · Berend-Jan Lange

Almost every app needs to know who is using it, and the login is where a proof of concept cuts its corners: a shared password, an admin page anyone can reach, a “forgot password” link that mails nothing because no mail server was ever set up. Since 22 October every Basable environment with a cluster comes with a login it can offer from its first deploy, and the assistant wires it in when it builds sign-in.

What your app gets

Each environment’s cluster carries a Secret named basable-login, written and kept there by the platform. It holds an issuer, a client id and a client secret: an OpenID Connect client of Basable’s own login, made for that environment. Preview and live each have their own. The platform registers the callback on every address of the environment, your custom domains included, and if the Secret is ever deleted it comes back with the same value, so a running app keeps working.

Nothing to register, no keys to copy from a console, no mail server to set up.

What the person sees

They click “Sign in with Basable” in your app and land on basable.com. Someone who is signed in there sees one page, saying that your app wants to sign them in with their Basable account, and only the first time; after that the round trip answers itself and they are back in your app, signed in. Someone without an account can make one there with just their email address. Account Settings lists every app a person has let in, and Disconnect makes the next sign-in ask again.

What your app learns, and what it does not

Two things: an id for the person and their email address.

The id is only valid for your project. Two apps on Basable get two different ids for the same person, so they cannot match up their users behind their backs.
The email is a proven one, or none at all. An account on basable.com is always made with an emailed code, so its address has been proven. An address changed later without proof is never handed to an app; the app then gets the id alone, and the login the assistant builds refuses the sign-in, since it finds its people by email.

Nothing about the person’s organisations, projects or anything else they do on Basable reaches your app.

Your app keeps its own users

Sign in with Basable is one way in, not a replacement for your own accounts. The assistant builds login on Ory Kratos, which keeps a user of its own for every person and can offer email codes and passkeys beside the Basable button. When someone first registered by email code and later clicks Sign in with Basable with the same address, Kratos asks them to sign in the old way once and then links the two. Nobody takes over an account by registering its address somewhere else first.

Kratos is a choice, not a requirement. Any OpenID Connect library works, as long as its callback is one of the two paths the platform registers. The discovery document is at basable.com/.well-known/openid-configuration, and the signing keys rotate every 30 days by themselves.

Who it is for

Every app on Basable shares the one sign-in, so a person signed in to one is a click away from the next. That suits internal tools best: your colleagues already have Basable accounts, and an admin page behind Sign in with Basable is closed to everyone else from the first deploy. For a public app it is a quick first login, with your own sign-up beside it for people who would rather not make a Basable account.

What is not there yet

Basable is the only sign-in provider the platform sets up for you. Google, GitHub or Microsoft go into Kratos with keys of your own, the way they would on any server. The page that asks for consent names your project but carries Basable’s look, not yours. And an account on basable.com is a Basable account: the person sees our name, and we hold their email address, which is why the app keeps its own users beside it.