# 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](https://www.udibo.com/docs/identity/mfa) 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](https://www.udibo.com/docs/identity/users#add-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](https://www.udibo.com/docs/identity/social-login) and
  [choosing who can create an account](https://www.udibo.com/docs/identity/sign-in-methods#decide-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:

| Method  | Path                         | Scope                    |
| ------- | ---------------------------- | ------------------------ |
| `PATCH` | `/api/identity/tenants/{id}` | `identity:tenants:write` |

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._

```ts
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](https://www.udibo.com/docs/identity/apis#the-management-api).

_Last verified 2026-10-03._