Beta

Create a tenant

A new tenant starts with its own users, OAuth settings, audit history and logs. You are its first Tenant Admin.

BTL Admin

Sign-in methods in your tenant

Each tenant chooses how its users sign in, from passwords to passkeys, and how strictly each method is rolled out.

Authentication settings

Open Authentication in the tenant sidebar. Five methods are available: passwords, email sign-in links, email one-time codes, authenticator apps, and passkeys or security keys. Each method has a rollout: Off, Optional, or Required. The page also shows how many users have set up each method.

Method settings include how long email links and codes last, whether a link may be opened on another device, the name shown in authenticator apps, and whether passkeys need a PIN or biometric, which kind of authenticator to prefer, and whether a passkey alone can sign someone in. The preferred kind is a preference, not a guarantee: the browser offers that kind when a user adds a passkey and reports which kind it used, but the report is not signed and some browsers leave it out. You can also decide when to ask for a second step, whether users who hold management roles always need one, how many days a browser can be trusted to skip it, and how many recovery codes each user gets. Registration settings control whether people can create their own accounts on your sign-in page and whether users can change their own email address.

Changing these settings needs the Authentication update permission, which the built-in Tenant Admin role has and custom roles can include. Every change is recorded in the tenant's Audit. Settings that would leave users without a way to sign in are refused.

Optional and required methods

An Optional method appears on each user's Security page, and new users are offered it once after registering. A Required method is a forced migration: new users set it up while registering, and existing users sign in the usual way one last time, then set it up before they can continue.

A Required method can have a deadline. After the deadline, users who have not set up the method cannot sign in. An administrator with the reset permission can open the user's row in Users and choose Reset sign-in methods. That removes the user's methods, signs them out and gives them seven days to sign in and set up again. The user receives an email about the reset.

A Required sign-in method can also replace passwords. Set passwords to Optional or Off first. Each user's password is then removed as soon as they set up the new method.

Second steps

An authenticator app, passkeys and email codes can be second steps, and recovery codes stand in for a lost app or passkey. A second step is always a different method from the first, so the passkey used to sign in can never be its own second step. A password is something the user knows, an email link or code shows they control the mailbox, and an authenticator app, recovery code or passkey is something they have. An email code cannot follow an email sign-in, because both only show access to the same mailbox. An authenticator app can follow a passkey used without a PIN or biometric, so a stolen key alone is not enough, but because both are things the user has, that sign-in is not recorded as multi-factor. A passkey that checks a PIN or biometric proves two kinds at once and needs no second step.

When a second step is required but none of the user's methods can follow the way they signed in, they set up one that can before continuing. If no such method is turned on, a user who has a password is asked to sign in with it instead. Requiring a second step for users who hold management roles has no effect until an authenticator app, passkeys or email codes are turned on, and the Authentication page says so beside that setting.

Wrong second-step codes count for the account across every sign-in attempt. After too many, the second step pauses for the rest of the day, or until an administrator resets the user's sign-in methods. Wrong passwords count separately for each network they come from, so guesses from one place cannot lock the user out everywhere; an address that keeps failing from many networks is slowed instead. Each limit, and how many users it currently holds back, appears on your tenant's usage view.

What users see

Tenant users sign in on your tenant's own address, at /login. Applications that use your tenant send them there during an authorization request, and they return to the application once every step is done. The sign-in page offers each method you turned on, plus Create an account and Forgot your password? when those apply.

Signed-in tenant users have their own Your Profile and Security pages at /account and /account/security. There they can confirm their email address, change their password, turn email sign-in on or off, set up an authenticator app or passkey, create new recovery codes, and forget trusted browsers. Changing sign-in methods needs a recent sign-in, and changing a password also needs the current one. Users receive an email whenever a method is added or removed.

New passwords are checked against passwords known from data breaches, at registration, reset, on the Security page and when an administrator sets one. If the check cannot run, the password is not accepted and the user can try again shortly. A password change or reset ends the user's other sessions and signs them out of applications, and a reset also ends any sign-in links and codes still waiting in their mailbox. When users change their own email address, their other browsers and applications are signed out and links already sent to the old address stop working.

When an administrator changes a user's email address in Users, the new address must be confirmed before email sign-in and codes work again, and the user is signed out everywhere. Because password reset links go to that address, changing it also needs the permission to set user passwords. Changing only the user's name keeps them signed in; applications see the new name the next time they receive tokens.

Sign-in methods in tokens

ID tokens carry an amr claim listing how the user signed in, using the values registered in RFC 8176 where one fits. pwd means a password. otp means a one-time code: an email code, an authenticator app code or a recovery code. hwk means a passkey kept on one device and swk a passkey synced between devices. mfa means two different kinds of factor were proved, or a passkey checked a PIN or biometric. An email sign-in link adds email, a value of our own, because no registered value describes it.

A user who signs up through the registration page gets email or otp, depending on whether they confirmed with the link or the code. A user who sets up a required method while signing in also gets that method's value, but not mfa, because the method was not proved independently of the first step.

Tenant users with management roles

A tenant user can manage your tenant when you give them a management role. In Users, choose Management roles on their row and select the built-in Tenant Admin role or a custom role. They then manage the tenant at /manage on your tenant's address, and can do exactly what their roles allow. A tenant user's roles never reach Beyond the Login or another tenant, and at least one BTL Tenant Admin must always remain.

BTL accounts

Beyond the Login accounts follow the same kinds of settings, managed by BTL administrators for BTL's own organization. Your account's Security page shows the methods BTL offers and the ones you have set up.

We value your privacy

We use cookies and similar technologies to enhance your browsing experience, and analytics to understand our traffic. By clicking "Allow All", you consent to optional analytics. Cookie Policy

Website docs