Documentation

Console

Authentication codes

An authentication code is a second check on Windows / workplace login. It is not a password for Google or email login. You set it on the member. On-premise decides when the login page asks for it.

When this applies

All of the following must be true:

  1. The organization is on a live Enterprise plan.
  2. On-premise is enabled, and Allow Windows / workplace login is on.
  3. Settings → Login methods includes Windows / workplace.
  4. The page is opened on the organization URL, a verified custom domain, or the on-premise Bookmer host — never on bookmer.com.
  5. The reverse proxy sends the signed-in workplace user.

Social login, email codes, passkeys, and QR login do not use this field. Those methods already prove the LoginSign account. Details: Organization login and On-premise.

Set the code on a member

  1. Open Console → Users.
  2. Create or open the person.
  3. Optionally set Windows username (DOMAIN\user or the short name).
  4. Set Authentication code. Console stores only a SHA-256 hash. The value is never returned.

Leave the code empty if the organization policy is Off, or if the policy is “Only if set” and this person should skip the extra field.

POST  /api/developer/teamspaces/:id/members
      { "name", "email", "windowsUsername?", "authCode?", "permissionNodeIds?" }

PATCH /api/developer/teamspaces/:id/members/:memberId
      { "windowsUsername?", "authCode?" }

Send authCode as a string to set or replace it. Send null to clear it. Member payloads include authCodeSet: true when a hash exists. They never include the code or the hash.

Organization policy

Console → On-premise → Workplace login → Authentication code:

  • Off — the login page never asks. A stored hash is ignored.
  • Required for everyone — every workplace sign-in must send a code. Members without a hash cannot finish.
  • Only if set on the member — the field appears only when that member has a hash.
PATCH /api/developer/teamspaces/:id/on-premise
{ "windowsLoginEnabled": true, "authCodeMode": "off" | "required" | "if_set" }

Login request

The browser cannot read a Windows identity. IIS, Nginx, or Caddy with Kerberos/Negotiate must send X-Remote-User, Remote-User, or X-Forwarded-User. LoginSign maps that header to windowsUsername on the member (domain-qualified and short name both match).

POST /api/org/:slug/windows-login
{ "code"?: "…" }
  • No remote-user header → 401 no_remote_user.
  • Unknown username → 401 unknown_user.
  • Code required but missing → 401 code_required. The login page shows the field.
  • Wrong code → 401 invalid_code.
  • Host not allowed, or workplace login off → 403.

A successful call writes the LoginSign session and returns { ok: true, redirectTo }. Session length follows On-premise Session length: 4 hours, 8 hours, 24 hours, or until the window closes.

Integration checklist

  1. Enterprise plan live. Enable on-premise and workplace login.
  2. Enable Windows / workplace under Settings → Login methods.
  3. Map each workplace user in Users. Set codes if the policy needs them.
  4. Configure the reverse proxy header on the organization host only.
  5. Open /org/:slug/login on that host. If the policy asks for a code, submit it in the same POST.