Passwordless sign-in

Magic links and one-time email codes: single use, short-lived, enumeration-safe, and opt-in per organization.

Passwordless sign-in lets a user authenticate with proof of mailbox possession instead of a password. Obexal supports two methods, both opt-in per organization and both going through the same MFA rules as any other primary factor.

How it works

In both cases the server stores only a hash of the token or code, never the raw value, and consumes it atomically on verification: a link or code can be used exactly once.

Enable it for your organization

Passwordless sign-in is off by default and fail-closed: unless your organization has explicitly enabled it, start requests are refused with 403 passwordless_disabled (a policy response that reveals nothing about accounts).

• Console: open your organization settings and enable the passwordless sign-in toggle ("Autoriser la connexion sans mot de passe").
• API: the switch is the allowPasswordless key of the organization's branding object. Read the current object first, then send it back updated:

# Read the current branding object.
curl -sS https://accounts.obexal.com/v1/admin/tenant \
  -H "Authorization: Bearer $OBEXAL_API_TOKEN"

# Send it back with allowPasswordless set to true.
curl -sS -X PATCH https://accounts.obexal.com/v1/admin/tenant \
  -H "Authorization: Bearer $OBEXAL_API_TOKEN" -H 'Content-Type: application/json' \
  -d '{"branding":{"allowPasswordless":true}}'

Request a link or a code

curl -sS -X POST https://accounts.obexal.com/v1/auth/passwordless/start \
  -H "X-CSRF-Token: $CSRF" -H 'Content-Type: application/json' \
  -d '{"email":"a@b.eu","method":"link"}'
# 202 -> {"status":"ok"}

method is link (default) or otp. The response is always 202, whether or not the account exists: if the address is unknown, inactive, or malformed, nothing is sent and the response is identical (anti-enumeration). Requests are rate limited per email address and per IP (429 rate_limited).

The magic link points to the hosted sign-in UI (/passwordless/verify?token=...), which submits the token for you.

Verify and sign in

Verification takes either the link token or the email plus code:

# Magic link.
curl -sS -X POST https://accounts.obexal.com/v1/auth/passwordless/verify \
  -H "X-CSRF-Token: $CSRF" -H 'Content-Type: application/json' \
  -d '{"token":"dGhpc0lzVGhlVG9rZW4..."}'

# Or email code.
curl -sS -X POST https://accounts.obexal.com/v1/auth/passwordless/verify \
  -H "X-CSRF-Token: $CSRF" -H 'Content-Type: application/json' \
  -d '{"email":"a@b.eu","code":"429188"}'
# 200 -> {"user":{...}} and the session cookie is set

Any failure (invalid, expired, already used, attempts exhausted) returns the same generic 401 invalid_or_expired. Two side effects on success:

• The email address is marked verified: a passwordless sign-in proves possession of the mailbox.
• If the account has an active MFA factor, no session is opened; you get {"mfaRequired":true,"mfaToken":"...",...} to complete via the MFA chokepoint, like any primary factor.

Security model

• Opt-in, fail-closed: disabled unless the organization's branding.allowPasswordless is explicitly true; a missing or malformed setting means off.
• Hashed at rest: tokens and codes are stored as hashes and consumed on first use.
• Short-lived: 15 minutes for links, 10 minutes for codes.
• Enumeration-safe: start always answers 202; verify always fails with the same generic error.
• Rate limited: per email and per IP on start, per IP on verify.
• MFA preserved: passwordless is a primary factor and never bypasses an enrolled second factor. For a phishing-resistant alternative that needs no email round-trip, see Passkeys.