neosourceDocs
Search docs

Begin registering a passkey

POST/api/auth/webauthn/register/start

webauthnRegisterStart

Sudo-gated, with the same first-credential bootstrap as TOTP enrolment: an account that holds nothing to step up *with* — an OAuth-claimed account with no password and no TOTP — may enrol its first passkey without a prior sudo grant, because it could otherwise never obtain one. Any account that already holds a credential must sudo first. Returns a `challenge_id` plus the `publicKey` options to hand to `navigator.credentials.create()`. The account's existing credential IDs are included as `excludeCredentials`, so an authenticator the account already holds will refuse to enrol a second time rather than silently creating a duplicate. The ceremony expires after five minutes and the `challenge_id` is single-use.

Requires authentication using a session cookie — see tokens and scopes.

curl

curl -X POST 'https://neosource.dev/api/auth/webauthn/register/start' \
  -b 'ns_session=$NEOSOURCE_SESSION'

fetch

fetch("https://neosource.dev/api/auth/webauthn/register/start", {
  method: "POST",
  credentials: "include",
});

Responses

200Ceremony started

application/json

PasskeyRegisterStartResponse

object

A started registration ceremony.

challenge_idrequired

string

Opaque handle for the in-flight ceremony. Echo it back to `/finish`. Single-use, and expires after five minutes.

optionsrequired

The `publicKey` argument for `navigator.credentials.create()`. Pass through verbatim.

403Sudo required — the `challenge` field names which sudo-prove endpoint to call

application/json

SudoRequiredError

object

Wire shape of the 403 a sudo-gated endpoint returns when sudo is missing or expired. `challenge` tells the SPA which sudo-prove endpoint to call.

challengerequired

string

Which sudo-prove endpoint the account should use: `"passkey"` (`/api/auth/sudo/passkey/{start,finish}`), `"password"` (`/api/auth/sudo/password`), or `"totp"` (`/api/auth/sudo/totp`), chosen from the account's registered credentials — passkey first when present, since it is both the strongest credential and the least friction. A hint for which prompt to show first, not an authorization decision: each sudo route verifies its own credential regardless of what was advertised here, so a client may use a different one.

errorrequired

string

Always `sudo_required` — this body exists to carry the extra fields that kind needs.

"sudo_required"

messagerequired

string

Standard errors

Bodies documented once for the whole API — see standard errors.

  • 401Authentication required
  • 429Rate limited — retry after the `Retry-After` header
  • 500Passkeys are not configured on this deployment
  • 503Service temporarily unavailable / at capacity — retry after the `Retry-After` header
  • 504Gateway timeout — the request exceeded the server's handling budget