Login methods

Every way a guest can sign in, what each needs configured first, and what it costs.

Choosing methods for a journey

Captive Portal → Login Methods lists every sign-in and registration mechanism Kiwire supports, grouped into four categories: login (one-click, SMS OTP, WhatsApp OTP, social, Active Directory, LDAP, QR login, default login, voucher login, Microsoft Entra ID, external database, API, MyDigitalID, SAML, Okta, payment), registration (sponsored signup, public signup, email OTP, OAuth2 email), utility (check usage, top-up), and account recovery (forgot password, forgot password via OAuth2, change password). Each method type can have several named instances — for example two SMS OTP setups pointing at different SMS connectors, each with its own access profile and set of zones. A journey or portal template picks specific instances to decide what a guest actually sees at a given SSID or zone; a method that exists here but isn't referenced by any journey never reaches a guest.

Most method types also require a specific permission to be offered — the card for SMS OTP, for instance, only shows up for an admin who can manage the SMS connector. An instance is saved with the zones it applies to and, for most types, the access profile a successful login is granted.

SMS and WhatsApp

SMS OTP and WhatsApp OTP send a one-time code to the guest's phone. Both need a connector configured first — under Connectors, an SMS connector for SMS OTP, a WhatsApp connector for WhatsApp OTP — before the login method's own form has anything to select; the SMS OTP card itself is gated behind the manage-connector-sms permission, WhatsApp OTP behind manage-connector-whatsapp.

SMS OTP configuration covers the message content template, which connector sends it, an optional "+" prefix and allowed phone country codes, a resend cooldown, and the usual profile/validity/zone assignment. WhatsApp OTP adds a resend cooldown, a cap on verification attempts, and separate pages for the verification step, success and failure.

Email

Two email-based sign-ins exist: Email OTP, which needs an SMTP connector (manage-connector-smtp), and OAuth2 Email, which needs an OAuth2 connector (manage-connector-oauth2). Both are configured with a message template, a resend cooldown, and pages for verification, success and failure, plus the standard profile/validity/zone fields.

These two are for registering. A guest who enters an email address that is already registered and verified is told "This email is already registered. Please use the login option to access the WiFi." — so put a sign-in method such as Default Login on the same journey for returning guests.

Sponsored sign-up

With Sponsored Signup the guest fills in a short form and names a sponsor — a host or staff member — who gets an email asking them to approve the request. You choose the email sent to the sponsor and the one sent to the guest once approved, which sponsor email domains are allowed (for example only your company's domain), and whether the form is Registration Only or Registration + Login (already-approved guests can sign in from the same form; if they type an updated name or other details, their account is updated). Turn on Auto Login on Approval and the guest's portal page signs them in by itself as soon as the sponsor approves, with no button to press.

Account recovery has its own pair of methods that ride on the same connectors — Forgot Password (SMTP) and Forgot Password via OAuth2 — each pointing at a message template and letting the admin choose whether a successful reset grants temporary access before the guest sets a new password. If you would rather send the reset link by text message, set Forgot Password Method to SMS under Administration › Settings › General: the guest types their phone number, username or email, and the link goes to the phone number on their account through your SMS connector, worded by the SMS template you pick there. The password rules themselves (length, reuse, lockout, change on first login) are in the Password Policy card on the same Settings page, because they apply to every account.

Vouchers and top-up codes

Voucher Login needs no connector at all — a guest enters a pre-generated voucher code and is signed in directly against it, scoped only by zone. Top-up is a utility method that lets a guest with an existing account apply a top-up code to add credit or time, with a toggle for whether it logs them in immediately afterward. A related utility, Check Usage, lets a guest look up their own remaining balance without any connector or login at all — its exposed fields (which balance columns to show, and their labels) are configurable per instance.

Social sign-in

The Social method signs a guest in through one or more OAuth providers — the provider list is chosen per instance, and each provider needs its own connector configured under Connectors first; the card is gated behind manage-connector-google as a stand-in permission for the social group. Beyond the provider choice, a social instance only needs an access profile and the zones it applies to.

PMS (hotel room and surname)

Room-and-surname sign-in isn't itself a Login Methods entry — it's the output of the PMS connector (Connectors → PMS). When a hotel's property-management system sends a check-in event, Kiwire looks up the guest's Kiwire account by a username derived from the room number and updates it: full name from the guest's first/last name, and a password computed from the connector's password-mode setting — a fixed predefined value, the room number itself, the first name, the last name, or the full name, with a percentage setting controlling how much of the name is used. The account is marked as PMS-integrated. Check-in only updates an existing account; if none exists for that room, Kiwire logs an error rather than creating one.

The guest then signs in through an ordinary method — typically Default Login — using the room number as username. At login time Kiwire re-derives the expected password from the same password-mode rule, so the two sides always agree without the plaintext password being stored anywhere separately. Check-out deactivates the room's account.

MAC and auto-login

One-Click is Kiwire's silent sign-in: with its "login using" option set to MAC, the guest's device MAC address (stripped of separators, lowercased) is used as both username and password against a shared or per-device account, with no form shown at all. Set to fingerprint, a browser-generated hash takes the MAC's place, falling back to MAC if the fingerprint is missing or malformed (for example when JavaScript is blocked). A third mode, username, signs everyone in against one shared username/password pair.

Separately from One-Click, Kiwire checks for an existing auto-login before showing the portal at all — it recognizes five kinds: a previously issued cookie, MAC, zone-level auto-login, browser fingerprint, or a QR code. A guest who already has one of these doesn't see a login page again for as long as the relevant policy window allows.

Browser fingerprint auto-login is switched on under Captive Portal › Configuration, next to its limits: Browser Fingerprint Auto Login Days (how long a device stays recognised after it last signed in) and Only Same Zone (recognise it only in the zone where it last signed in). If two different accounts ever sign in from devices with the same fingerprint — identical phones, for example — that fingerprint is set aside and never used for auto-login again, so one guest can't be signed in as another.

The phone's own captive-portal window (on iPhones and many Android phones) often forgets cookies between visits, which normally stops fingerprint auto-login working there. Turning on Also recognise browsers that keep no cookies lets Kiwire recognise those devices from the fingerprint alone. It is off by default and stricter than the normal check: the device is only recognised in the zone where it last signed in, and only within the days limit above.

Enterprise (802.1X and certificates)

WiFi Enterprise is a separate area from Captive Portal, used for guests self-enrolling a device onto an 802.1X SSID rather than clicking through a captive portal page. Its own Login Methods page offers a narrower set — a registered Kiwire account, or Google, Microsoft Entra, Active Directory, WhatsApp or SAML — and, as with Captive Portal, every method besides the built-in registered account needs its matching connector configured first.

An enterprise login method only does something once it's wired into a Journey (which ties a portal template, a login method, and certificate issuance together) and that journey is published and assigned to a Portal Configuration for a given SSID. A published portal configuration with certificate-based device profiles turned on hands out working EAP-TLS/EAP-TTLS profiles only while the platform's RADIUS server certificate — a single root CA and server cert shared across every tenant, managed by Synchroweb — hasn't expired.

The form for one enterprise method instance (/admin/wifi-enterprise/login-method) carries these fields; the connector-backed methods (Google, Microsoft Entra, Active Directory, WhatsApp, SAML) get the full set, while Registered Account has only the name, the active switch, the certificate expiry and the email allow/block lists.

Field	What it does
Active	The instance's active switch, shown on its card in the list.
Name	Instance label, unique per method type (e.g. "Company A - Microsoft Entra").
Method type	Which of the six method types this is; fixed once created.
Profile	The access profile the enrolled account is created under. Required for every connector-backed method, absent on Registered Account.
Account expiry	Days before the account created through this method expires (default 1825). Connector-backed methods only.
Certificate expiry	Lifetime, in days, of the client certificate issued to the device at enrolment (default 365).
Allow account creation	Whether a guest with no existing account may register one through this method. Not offered on Registered Account.
Auto activate	Activate a newly registered account immediately instead of waiting for admin approval. Not offered on Registered Account.
Allowed email domains	Comma-separated domains allowed to sign in; empty allows all. Not offered on WhatsApp.
Allowed emails	Specific addresses allowed, one per line; empty allows all. Not offered on WhatsApp.
Blocked emails	Addresses blocked, one per line. Not offered on WhatsApp.
Blocked domains	Domains blocked, one per line. Not offered on WhatsApp.
Connector	The matching connector (Google, Microsoft, Active Directory, WhatsApp or SAML). Required for every connector-backed method.
Saved attributes	Google and Entra only: comma-separated OAuth response attributes (Google) or token claims (Entra) to copy onto the user profile; blank saves all.

When someone leaves. A device enrolled through Google or Microsoft keeps connecting on its own profile and does not sign in to Google or Microsoft again, so deleting the person there does not by itself remove their WiFi. Switch on Directory check on the Google or Microsoft connector. Once a day Kiwire suspends and disconnects anyone deleted or suspended in the directory, and reactivates them if they come back. To cut someone off immediately, suspend their account in Kiwire: their devices are refused at the next connection.

Group and attribute mapping. The Profile field is the default; two of the methods can override it per user. Active Directory has a group-mapping list (group name, priority and profile per row, each row with its own enable toggle): each row names a group by its full distinguished name, and at login the user's group memberships are compared against the enabled rows in priority order — lower number wins when a user is in several groups — and the first match sets the profile; no match falls back to the Profile field. SAML has an attribute-mapping table (field, match value and profile per row) instead: the field list is the connector's own attribute mappings (plus full name and phone number), and a row whose field equals the match value exactly switches the user's current profile to that row's profile. WhatsApp adds four fields of its own — OTP expiry (minutes a one-time code stays valid, 1–60), phone prefix (comma-separated country prefixes allowed, e.g. +60, +1), allowed phones and blocked phones (numbers allowed or blocked, one per line) — in place of the email lists.