1. Introduction to Hotspot Authentication in RouterOS
When a guest joins your Wi-Fi and a login page appears, MikroTik RouterOS hotspot authentication is the part that decides whether that guest gets online. It checks who the client is, applies the rules you attached to that client, and keeps track of the session afterward. If you run a small hotspot or a WISP, understanding how MikroTik hotspot authentication works saves you a lot of guesswork when someone says “I can’t log in.”
Method choice matters more than most operators expect. The login method you pick affects whether a client sees a form at all, how credentials travel from the browser to the router, how long a returning device stays signed in, and which log entries you will read when something breaks. A method that suits a cafe with walk-in guests may frustrate a residential customer who expects to stay connected.
This article stays focused on RouterOS hotspot login behavior only. I will not cover wireless tuning, firewall design, or hardware choices. I will explain each login option in plain terms, show you how they relate to each other, and give you a practical way to chase down failed logins. If you later want to pair logins with charging for access, a MikroTik hotspot billing platform is a natural next read once your login method is settled.
2. How Hotspot Authentication Fits in the Connection Flow
Connection flow is easiest to understand as a short journey. A device joins the network and receives an address. The device then tries to reach something on the internet, and the router steps in. Until the client proves who it is, or until a method recognizes it automatically, the router keeps it in a limited state. After a successful login, the router moves the client into a permitted state and traffic flows normally.
Authentication is the gate in the middle of that journey. Everything before it is about holding and redirecting the client, and everything after it is about session control. Before any of this works, your router has to be reachable and prepared, and a guide to Connect MikroTik router platform tooling can help with that groundwork.
2.1 Role of the captive portal in intercepting client traffic
Captive portal interception is what makes the login step unavoidable. When an unauthenticated client opens a web page, the router catches that request and sends the browser to the hotspot login page instead of the page the user asked for. This is captive portal authentication in practice: the client cannot reach its destination until the login step finishes.
For you as an operator, this explains a common symptom. If a client never sees the login page, the interception is not reaching the browser, so you start your checks at the redirect rather than at the credentials.
2.2 Interaction between unauthenticated clients and RouterOS services
An unauthenticated client is not blocked from everything. RouterOS holds it in a limited state where it can reach only what the hotspot needs to run the login. The Hotspot Server service handles the redirection, serves the login page, and processes whatever the client submits.
Behind that service, RouterOS consults the settings you attached to the Hotspot Profile and decides how to handle the attempt. If the profile calls for a form, the client sees the form. If the profile allows a method that recognizes returning devices, the router may skip the form entirely. Keep this in mind when you troubleshoot, because the same limited state can end in very different experiences depending on the method.
2.3 How successful authentication changes client access state
When authentication succeeds, the router changes the client’s state from limited to permitted. The client’s traffic no longer gets redirected, and the session now carries the rules tied to that user. A Session timeout may apply from that moment, and it decides how long the permitted state lasts before the client must authenticate again or get renewed.
You can use this as a quick mental test. If a client logs in successfully but the next page load shows the login page again, the state change is not sticking, and you should look at session handling rather than the form.
3. Overview of Login By Authentication Methods
Every RouterOS hotspot uses the login-by setting to decide which authentication methods clients may use. This is the setting that answers the question behind how RouterOS hotspot login by works: it tells the router which paths are open to a client and which are not. Those choices live in the Hotspot Profile, while the rules that apply after login live in the user data attached to each client. For the everyday side of accounts, see MikroTik hotspot user management.
Keep two layers separate in your head. The RouterOS hotspot profile controls how clients are allowed to authenticate. The RouterOS hotspot user profile controls what an authenticated client receives. Mixing those up is a classic source of confusion when a login works but the access looks wrong.
3.1 List of available login by options in hotspot profiles
The MikroTik hotspot login by options cover form logins, device recognition, no-credential access, and backend-driven approaches:
- HTTP PAP: The client submits credentials through the login form in a direct way.
- HTTP CHAP: The client answers a challenge from the router, so the form does not send the password the way PAP does.
- HTTPS: The login page itself is served over a secure connection, which changes how credentials are protected in transit.
- MAC: The router recognizes a returning device by its MAC address and can skip the form.
- Cookie: The router recognizes a returning browser through an HTTP cookie that remembers an earlier login.
- Trial: A Trial user gets limited access without entering credentials.
- RADIUS: The router sends credentials to a backend that makes the decision, which also supports voucher access when the backend validates the codes.
You can enable several of these at once, and that is where choosing carefully pays off.
3.2 How multiple login methods can operate together
Multiple methods can run on the same hotspot at the same time. A client might get recognized by cookie on one visit, use the form on another, and rely on trial access on a third. From the client’s side, this feels flexible. From your side, it means a single complaint can involve several possible paths.
When you troubleshoot, always ask which method the client actually used. A login that works by form but fails by MAC points to a very different problem than a login that fails everywhere. Writing down which methods are enabled before you start testing keeps your diagnosis honest.
3.3 How RouterOS selects an authentication path for a client
RouterOS picks the path from two things: what the profile allows and what it knows about the client at that moment. If a recognized device or browser session matches an enabled method, the router can authenticate without a form. If nothing matches, the client lands on the login page and chooses from whatever options the profile offers.
This is why changing a setting sometimes appears to change nothing. A client that already has a valid recognition entry follows the recognition path and never sees the form you just edited. Test with a client that has no earlier state, then test again with one that does, so you see both paths.
4. HTTP CHAP and PAP Authentication
HTTP CHAP authentication and HTTP PAP authentication are the form-based login methods. In both, the client types a username and password into the hotspot login page. What differs is how those credentials leave the browser. This section focuses on the concepts so you can choose a method and read a failure correctly, not on setup steps.
4.1 How HTTP CHAP challenge handshake works
With CHAP, the router first gives the login page a challenge. The page then combines that challenge with what the user typed and submits the result instead of the raw password. The router checks the response against what it expects. People use this approach for login forms because the password does not travel in plain form during submission.
The practical effect is that CHAP depends on the login page doing its part correctly. If a customized page breaks the handshake, valid credentials will still fail, which is worth remembering before you blame the user.
4.2 How PAP credential submission works
PAP is the direct approach. The user fills in the form, and the page submits the credentials as entered. The router receives them and checks them against its user data or its backend. There is no challenge step, so there is less that can go wrong inside the page itself.
That simplicity is useful when you need a straightforward login that behaves predictably. The tradeoff is that the credentials travel as submitted, so how you protect the connection matters, which I cover in the HTTPS section.
4.3 Differences in credential handling between CHAP and PAP
The comparison of HTTP CHAP vs PAP in MikroTik hotspot comes down to what leaves the browser. CHAP sends a response built from a challenge, while PAP sends the credentials directly. CHAP adds a handshake that depends on the login page, and PAP removes that dependency.
To choose, ask what you value more. If you want credentials to avoid direct transmission over a plain connection, CHAP fits better. If you want fewer moving parts or you use a heavily customized login page, PAP is easier to reason about. When a login fails under one method and works under the other, suspect the page or the handshake before the account.
5. HTTPS Based Login Handling
HTTPS hotspot login serves the login page over a secure connection instead of a plain one. The visible goal is simple: the browser and the router talk through a protected channel while the user submits credentials. The practical effects show up in how browsers treat the page and in what you must prepare on the router.
5.1 How secure login pages process credentials
To understand how HTTPS login works in MikroTik hotspot, picture the same login form wrapped in a secure session. The browser establishes the secure connection first, then the user submits the form, and the router processes the credentials the same way it would for HTTP. The difference is the protection around the exchange, not the decision logic after it.
This means HTTPS complements your method choice. You can run PAP or CHAP behind a secure page, and the secure page changes how the submission travels rather than which method decides access.
5.2 Certificate requirements for hotspot HTTPS login
A secure login page needs an SSL certificate so the browser can trust the page it reaches. At a conceptual level, the router has to present a certificate that the client’s browser accepts, and the setup has to line up with how clients reach the login page. If the browser does not accept what the router presents, users will see warnings or blocked pages.
I will not go into specific certificates or authorities here. What matters for you is the principle: HTTPS login adds a certificate requirement that HTTP login does not have, and many HTTPS login complaints trace back to that requirement.
5.3 Common behavior differences between HTTP and HTTPS login
Operators usually notice HTTPS differences in the browser first. Users may see security warnings, a login page that refuses to load, or redirects that behave differently than they did over HTTP. Some devices handle the captive portal check more strictly when secure pages are involved.
When a client works on HTTP login but struggles on HTTPS, check the certificate story before anything else. If the secure page loads cleanly and the credentials still fail, the problem sits in the method or the user data instead.
6. MAC Authentication and Cookie Sessions
Both MAC and cookie approaches exist so that returning clients do not face the login form every time. They recognize the device or the browser and restore access without asking again. The result is smoother for the user and quieter for your support inbox, but it adds state that you need to understand when something misbehaves.
6.1 How MAC login identifies returning devices
To see how MAC authentication works in MikroTik hotspot, start with the MAC address. Every client presents one, and the router can treat it as the identity of the device. When the hotspot allows MAC login, the router looks for a matching entry for that address and, if it finds one, authenticates the device without a form.
MAC hotspot authentication suits devices that cannot or should not type credentials, and it suits returning guests you want to reconnect smoothly. Note that the recognition belongs to the device. If a user changes devices, the new device has no entry and goes through another method.
6.2 How cookie login preserves authenticated sessions
For how cookie login works in MikroTik hotspot, think of the browser carrying a small token. After a successful login, the router can hand the browser an HTTP cookie. On later visits, the browser presents that cookie, the router recognizes it, and the session resumes without the form.
Because the cookie lives in the browser, cookie hotspot login follows the browser rather than the device. A user who clears stored data or switches browsers will see the login page again, and that is expected behavior rather than a fault.
6.3 Session timeout and renewal behavior for MAC and cookie entries
Recognition entries do not last forever. A Session timeout governs how long an entry or session remains valid, and when it ends the client falls back to another method, usually the login form. Renewal behavior determines whether continued use extends the entry or whether the client must authenticate again.
I will not suggest specific values, because the right choice depends on your users. The useful habit is to decide on purpose. Short-lived recognition favors tighter control, and long-lived recognition favors convenience. When users complain about repeated logins, compare their experience against the timeout and renewal behavior you configured.
7. Trial Access and Voucher Based Login
Trial and voucher logins are credential-light options. Neither expects a long account setup, and both tie back to user profiles that define what the client receives. They work well when you want quick onboarding. If you are thinking about WiFi voucher access sales, the concepts below show how voucher logins behave at the router.
7.1 How trial login grants limited access without credentials
To grasp how trial access works in MikroTik hotspot, picture a client that wants a quick taste of the service. With trial hotspot access enabled, the client can get limited access without typing credentials. The router treats it as a Trial user and applies the limits attached to that kind of access.
Trial sits alongside other methods rather than replacing them. A client can try the service first and later move to a form login or a voucher. When troubleshooting, check whether the client entered through trial, because trial limits can look like a fault if you forgot they apply.
7.2 How voucher codes are entered and validated
For how voucher login works in MikroTik hotspot, the flow is straightforward. The user enters a Voucher code on the login page, and the router validates it either against its own user data or through a backend such as RADIUS. A valid code gives the client access under the rules attached to it. An invalid or already unusable code is refused.
From the user’s side, hotspot voucher login feels simple because they only handle a code. Your job is to make sure the code reaches the right place for validation, so confirm which side owns that check before testing.
7.3 Relationship between trial users, vouchers, and user profiles
User profiles tie these methods together. A trial user and a voucher user both end up governed by a User Profile, which defines what that kind of access includes. The login method gets the client in, and the profile shapes the session afterward.
This relationship helps you separate problems. If a voucher is accepted but the access is wrong, review the user profile. If the voucher is rejected, review validation and where it happens.
8. RADIUS Integration for Hotspot Authentication
RADIUS hotspot authentication moves the login decision away from the router’s own user data and onto a backend. The router still runs the hotspot, serves the login page, and enforces the result, but the backend answers the question of whether this client may proceed. For a broader look at the topic, read about RADIUS authentication for hotspots.
This setup suits operators who want central control, especially when voucher access or account data lives on a backend instead of on each router.
8.1 How RouterOS forwards hotspot credentials to RADIUS
To see how RADIUS authentication works for MikroTik hotspot, start with the RADIUS client role. RouterOS acts as the RADIUS client. When a client logs in, the router forwards what the user submitted to the RADIUS server and waits for an answer. The backend evaluates the credentials and replies.
Notice what stays the same: the client still sees the same login page and the router still holds the limited state while it waits. The only change is who decides.
8.2 Role of RADIUS attributes in access decisions
The reply from the backend carries the decision. Access Accept means the client may proceed, and Access Reject means it may not. RADIUS attributes can accompany the reply and shape how the session behaves once the client is in.
For your troubleshooting, treat an Access Reject as a real answer from the backend, not a router fault. The router did its job by asking, and the backend declined. Your investigation then moves to the backend’s account data and rules.
8.3 Handling of RADIUS timeouts and rejections
A RADIUS timeout is a different situation from a rejection. A rejection means the backend answered and said no. A timeout means no usable answer arrived, so the router cannot complete the decision. The client typically stays unauthenticated in both cases, but the cause and the fix are very different.
When you see failures, separate the two. Rejections point to credentials, accounts, or backend rules. Timeouts point to reachability or backend availability between the router and the server.
9. Troubleshooting Hotspot Authentication Behavior
Good troubleshooting starts by naming the symptom precisely. A client who never sees the login page has a different problem than a client who sees it and fails, and both differ from a client who logs in and gets bounced back. Work from the connection flow, check the cheapest explanations first, and avoid changing several settings at once.
9.1 Diagnosing failed logins and redirect loops
For MikroTik hotspot failed login causes, sort the failure into stages. Did the client reach the login page? Did the submission reach the router? Did the router accept or reject it? Each stage points to a different area: redirection, page handling, or the decision itself.
For a MikroTik hotspot redirect loop fix, look at state before settings. A loop usually means the router cannot hold the client in an authenticated state or cannot complete the step that moves the client out of the limited state. Check whether the method in use matches what the profile allows, whether session handling is sticking, and whether a secure page is causing the browser to refuse the redirect.
If the MikroTik hotspot login keeps repeating, compare that client with a fresh one. If a clean client works, stored state such as an old cookie or recognition entry is a strong suspect.
9.2 Reviewing logs for CHAP, PAP, MAC, and RADIUS events
Logs tell you which path the router took. For form logins, look for entries showing a login attempt and whether it succeeded or failed, and note whether the attempt used CHAP or PAP. For MAC, look for entries showing whether the router recognized the device. For RADIUS, look for signs that the router sent a request and what came back: an Access Accept, an Access Reject, or a RADIUS timeout.
Read the sequence, not just single lines. A failure with no sign of a RADIUS request suggests the router never reached the backend. A failure with a rejection suggests the backend said no.
9.3 Verifying hotspot profile and user database settings
Finally, confirm that your settings match your intent. Review the Hotspot Profile and check that the enabled login-by methods are the ones you meant to offer. Then review the user database and the User Profile attached to each account, voucher, or trial entry. Make sure they fit the method clients are using.
Consistency is the goal. A method enabled in the profile but unsupported by your user data, or a user profile that does not suit the access you sell, creates failures that look random until you compare the two side by side.
10. FAQ
10.1 What happens when a client first connects to a RouterOS hotspot?
The client joins the network and stays in a limited state. When it tries to open a web page, the captive portal intercepts the request and redirects the browser to the login page. Once the client authenticates, or a recognition method matches it, the router moves it to permitted access.
10.2 How does HTTP CHAP differ from PAP in RouterOS hotspots?
Both are form-based. With HTTP CHAP, the login page answers a challenge from the router and submits a response. With HTTP PAP, the page submits the credentials directly. CHAP adds a handshake, and PAP keeps the exchange simple.
10.3 When does RouterOS use MAC or cookie authentication instead of a login form?
RouterOS uses them when it recognizes a returning client. MAC authentication matches the device by its MAC address, and cookie login matches the browser by its stored HTTP cookie. If a valid entry exists and the method is enabled, the router skips the form.
10.4 How does trial access work alongside voucher login?
They coexist as separate paths on the same hotspot. Trial gives limited access without credentials, and voucher login accepts a code that the router or a backend validates. Both tie to user profiles that define what each kind of access includes.
10.5 How does RADIUS affect hotspot login decisions?
RADIUS moves the decision to a backend. RouterOS forwards the credentials, and the backend replies with Access Accept or Access Reject, possibly with attributes that shape the session. A rejection means the backend refused the client, and a timeout means no usable answer arrived.
10.6 What causes repeated login prompts or failed hotspot redirects?
Common generic causes include session state that does not stick, a mismatch between the enabled methods and the user data, stored cookie or recognition entries that no longer match, and secure page behavior that the browser refuses. Start by comparing a fresh client with an affected one, then verify the Hotspot Profile and user settings.