Passwordless sign-in

Let people who already have an eligible account with an email address sign in using their inbox. Two flows are built into your tenant's hosted sign-in page, each switched on separately, so there is no code to write and nothing to render yourself.

• Email code: the sign-in page emails a 6-digit code and the user types it into the same page. A code is single-use and expires after 10 minutes.

• Magic link: the sign-in page emails a link. Opening it shows a confirmation button — so a mail client or security scanner that prefetches the URL cannot spend it — and confirming completes the sign-in on that device. A link is single-use and expires after 15 minutes; an expired one sends the user back to the sign-in page to request a fresh one.

The same rules as every other sign-in

Both flows land in the same completion path as password and social sign-in, so passwordless is not a side door:

• Multi-factor authentication still applies. A user who owes a challenge under your MFA policy is challenged before any session exists — an emailed code does not stand in for a second factor.

• Ineligible accounts are refused indistinguishably. A disabled or deleted account answers exactly like a wrong code or a dead link, so the flow never confirms whether an address has an account.

• Requesting a code or link never reveals anything either. The response is the same whether or not the address is known, and requests are rate-limited per source and per address.

• A passwordless session is never a remembered session. An emailed credential is forwardable and often opened on a device the account holder does not control, so the session either flow creates ends with the browser session and is bounded by your tenant's session lifetimes either way — deliberately, and regardless of your remember-me settings. Password sign-in keeps its explicit remember-me checkbox.

Plan account creation before going email-only

Email codes and magic links sign in an existing account; they do not create one for a new email address. A request for an unknown address shows the same response as a known one and sends no sign-in email.

Before disabling passwords, choose how new people get an account:

• Create accounts in the dashboard. Open Users → Create user. Enter the required Username, First name and Last name, provide an Email address, leave Password blank, and choose Create user. This creates an end user of your application and sends no email. Direct the person to your tenant's sign-in page to request a code or link. See adding a user.

• Offer social sign-up. Configure an enabled connector under Providers and enable social sign-in under Security → Sign-in methods. New accounts still follow your open, closed or waitlisted registration policy. See social login and choosing who can create an account.

With passwords disabled and no social sign-up available, hosted account creation is unavailable even when registration is open. A waitlist invitation for a new person still needs password or social sign-up; it does not enable registration through an email code or magic link.

Test email sign-in with an existing eligible account before changing methods. Also test a new address and your chosen account-creation path, so the neutral request response is not mistaken for a delivery failure.

Turning the flows on and off

Each flow is its own tenant-level switch, on by default, edited in the dashboard under Security → Sign-in methods. The management API equivalent is listed for reference:

The authMethods object you send is merged into the current setting — a switch you omit keeps whatever it is set to, so you can send just the one you are changing. A policy that would leave every method off is refused, and the check runs on the merged result: turning off the last method your tenant still has is a 400 whether you name all four switches or only that one.

A tenant can go fully passwordless by turning the password method off and keeping every other method on — the hosted pages follow the policy, so the password form disappears everywhere it appears, account creation included:

Reference only — dashboard today.

const tenantId = process.env.UDIBO_TENANT_ID;
const response = await fetch(
  `https://www.udibo.com/api/identity/tenants/${tenantId}`,
  {
    method: "PATCH",
    headers: {
      authorization: `Bearer ${process.env.UDIBO_API_TOKEN}`,
      "content-type": "application/json",
    },
    body: JSON.stringify({ authMethods: { password: false } }),
  },
);
if (!response.ok) throw new Error(`update failed: ${response.status}`);

Naming only password is the whole request: emailCode, emailLink and social keep whatever they are set to. Send all four if you would rather be explicit — the result is the same when the values agree.

{id} is your tenant's id — the same one in your dashboard URL — and the token must hold administrative authority over that tenant.

Dashboard only today. These management API operations are listed for reference: they accept only the dashboard's own session or a token from Udibo's own sign-in, which you cannot get outside the dashboard. A token your tenant issues, including a client-credentials token, is refused with 401; see the management API.

Last verified 2026-10-03.