1. Introduction: Why Hotspot Logins Need Central Management
A hotspot often starts small. There is one router, a few guests, and a short list of people who are allowed to connect. A router is the device that links guests to the internet, and an access point is the device that provides the WiFi signal they connect to. At a small size, creating accounts directly on the router feels easy.
Things change as the hotspot grows. More guests arrive, each guest brings a phone and perhaps a laptop, and another router or access point may be added to cover more space. If every device keeps its own list of users, every change has to be repeated on every device. Adding a guest, removing a guest, or fixing a forgotten password becomes a chore that gets harder each time. The lists drift apart, and a guest who can log in on one device may be refused on another.
Centralized hotspot login management removes this problem by keeping the decisions in one place. Routers and access points stop acting as separate record keepers and instead ask one central system whether each guest may connect.
That central system usually handles three jobs. Authentication confirms who the guest is. Authorization decides what that guest is allowed to do. Accounting records what happened during the session. Together these are called Authentication Authorization Accounting, often shortened to AAA. The rest of this article explains each job in plain language, starting with the tool that delivers all three.
2. What RADIUS Is and What Problem It Solves
People often ask, “what is RADIUS and how does it work?” In simple terms, RADIUS is a method that lets a router or access point hand its login questions to a central authentication server. The server looks at the guest’s details, decides whether to approve them, and sends the answer back. The router or access point then follows that answer.
The problem this solves is scattered records. Without a central authentication server, each device must hold its own local device accounts, which means the same guest details have to be created, updated, and removed again and again. With RADIUS, the details live in one place and every device checks with that place. The sections below define the term, show where it sits, and compare the two approaches.
2.1 Definition of Remote Authentication Dial In User Service
RADIUS stands for Remote Authentication Dial In User Service. The name sounds old and technical, but the idea is easy to hold on to. So, what is RADIUS in everyday terms? It is a shared language that a network device and a central server use to talk about who may connect and what happens next.
The software that answers those questions is called a RADIUS server. It connects directly to the three jobs from the introduction. It supports Authentication Authorization Accounting by confirming identity, setting rules, and keeping records. Because it is the one place that makes these decisions, it acts as the central authentication server for the whole hotspot.
2.2 Where RADIUS Sits Between Users and the Network
Think of a building with several entrances. Each entrance has a guard, but the guards do not keep their own guest lists. Instead, each guard calls one office to ask whether a visitor may come in. The guards are the routers and access points, and the office is the central authentication server.
In a hotspot, a guest connects a phone or laptop to a router or access point. That device is the first thing the guest meets, but it does not make the final decision. It passes the guest’s login details to the central authentication server, waits for the reply, and then lets the guest in or keeps them out. The decision is made centrally, even though the guest only ever sees the router or access point.
2.3 Central Server Compared With Local Device Accounts
With a central server, there is one list of guests and one set of rules. When something changes, it is changed once, and every router and access point follows the new answer the next time a guest tries to connect.
With local device accounts, each device holds its own separate list. That works for a very small setup, but it becomes hard to maintain as the number of users grows or as more routers are added. Each new guest must be added to each device. Each removal must be repeated. A single missed update can leave an old account working, or leave a valid guest locked out. Spreading accounts across devices also makes it harder to see the full picture of who is using the hotspot.
For many users across one or more routers, the central approach saves effort and reduces mistakes.
3. Authentication: Confirming Identity Before Access
Authentication means confirming who someone is before they are allowed to use the network. It is similar to showing a ticket at a gate. The gate does not care yet what the visitor will do inside, only whether the visitor is genuine.
RADIUS authentication is the part of the system that does this check. The guest provides credentials, which are simply the details used to prove identity, and the central server compares them with its records. Two common methods are username and password authentication and voucher code login. For guests who visit only briefly, operators may choose voucher based hotspot access instead of a personal account.
Sometimes the check fails. Failed authentication handling is the way the system responds when the details are wrong, and it is covered at the end of this section.
3.1 Username and Password Checks
A common beginner question is: how does RADIUS authentication work for WiFi hotspots? The answer follows three simple steps.
First, the guest opens the login page and types a username and password. Second, the router or access point sends those credentials to the RADIUS server, which checks them against its central records. Third, the server replies that access is allowed or denied, and the router or access point acts on that reply.
This is username and password authentication. Nothing about the check depends on which router the guest used, because the answer always comes from the same central place. A guest can therefore use the same details whichever router or access point they reach.
3.2 Voucher Codes and Temporary Credentials
A voucher code is a code the operator creates in advance and gives to a guest, so the guest does not need a personal account. Voucher codes are a form of temporary credentials, meaning login details meant to be used for a limited purpose and then retired.
Here is how voucher code login works with RADIUS in simple terms. The guest enters the voucher code on the login page. The router or access point forwards it to the RADIUS server. The server checks whether the code is one it recognizes and is still valid, then sends back an approval or a rejection. From the router’s point of view, this looks just like any other login check, because the decision still comes from the central server.
3.3 How Failed Authentication Is Handled
Failed authentication handling describes what happens when the central server cannot confirm a guest’s identity. The credentials might have been typed incorrectly, the voucher code might not be recognized, or the details might no longer be valid.
In that case, the server sends back a rejection. The router or access point receives it and grants no access, so the guest stays outside the network. The guest is usually shown the login page again and asked to try again with the correct details. Because rejected credentials never lead to access, a wrong guess cannot slip through, and the operator keeps control of who gets in.
4. Authorization: Controlling What an Approved User Can Do
Once a guest has proven their identity, the next question is what that guest is allowed to do. This is authorization. Authentication answers who you are, and authorization answers what you may do now that you are in.
RADIUS authorization is how the central server sets those rules. Two common examples are session duration control, which limits how long a guest may stay connected, and speed and device limits, which shape how fast a guest’s connection can be and how many devices may share one login. Rules are grouped into an approved user access profile, which is a saved set of permissions attached to a guest. This section explains how RADIUS authorization controls session time and speed limits.
4.1 Session Duration and Access Profiles
Session duration control means a guest’s access lasts for a set period rather than forever. The period is decided by the operator ahead of time and is not tied to any single router.
To make this easy to manage, the rules are collected into an approved user access profile. Think of it as a label that carries instructions. When a guest logs in, the profile attached to them tells the system how long the session may last. This creates time boxed access, where the guest can use the network until the allowed time is used up and then access ends. Different kinds of guests can have different profiles, so one group can receive longer access than another without anyone editing individual devices.
4.2 Speed and Device Limits
Speed and device limits are two more examples of authorization rules. A speed limit controls how quickly a guest’s connection can run, which helps stop one guest from using more than a fair share of the available connection. A device limit controls how many devices can use the same login at the same time, which helps stop one login from being shared widely.
These rules are described here only in general terms. What matters for a beginner is the idea. They are not checks of identity. They are rules attached to an approved guest, decided by the central server and applied to the session.
4.3 How Authorization Rules Are Applied at Login
The rules are applied at the moment of login. After the central server confirms identity, it looks up the approved user access profile for that guest and sends the rules back together with its approval. This reply is the session approval response.
The router or access point reads the session approval response and enforces what it says. The session begins with the right duration, speed rules, and device rules already in place. Because the rules travel with the approval, no one needs to configure each guest by hand on each device.
5. Accounting: Recording Session Activity
Accounting means keeping a record of what happened during a guest’s session. Think of it as a logbook of activity rather than anything to do with money.
RADIUS accounting collects this record so the operator can review activity later and help guests who have questions. It relies on session start and stop records and on data usage tracking. This section covers how RADIUS accounting tracks session time and data usage. These records give operators material for real time session monitoring and for review after the fact.
5.1 Session Start and Stop Records
A session is the period during which a guest is connected and approved. When the session begins, the router or access point reports a start record to the central server. When the session ends, it reports a stop record. These session start and stop records mark the edges of every visit.
Together, the pair shows when a guest arrived and when they left. If a guest asks about their connection, the operator can look up the matching start and stop records and see the full span of the session.
5.2 Data Usage and Time Tracking
Between the start and the stop, the system can also keep track of how long the session has run and how much data the guest has used. Data usage tracking means measuring the amount of information that moved to and from the guest’s device during the session. Time tracking measures how long the guest stayed connected.
Both measurements support the rules from the authorization stage, since a session duration rule only makes sense if the time used can be measured.
5.3 How Accounting Records Support Review and Support
Accounting records are most useful when someone has a question. A guest might say that access ended too early, or that their time ran out sooner than expected. The operator can check past activity, find the session, and compare what the records show with what the guest reports.
For this to work, the records must be trustworthy. Log accuracy means the entries correctly reflect what actually happened. Time synchronization means the devices involved agree on the current time, so start and stop entries line up properly. If clocks disagree, a session might appear to end before it began, or records from different devices might not match. Keeping both in good order makes review and support much smoother.
6. How a Typical RADIUS Login Flow Works
This section explains how RADIUS login flow works from phone to router to server in plain steps. The order is always the same. The guest asks, the router or access point forwards the request, the central server decides, and the answer travels back. Beginners who want to go deeper can read about how captive portals work separately.
Keeping this order in mind makes it easier to see which part of the system is doing which job.
6.1 Connection Request From Phone or Laptop
The flow starts with the guest. They pick the hotspot’s WiFi name on their phone or laptop and open the login page. The device then sends a connection request, which is simply the guest’s attempt to get online.
At this point the guest has not been approved. They can see the login page, but the wider network stays closed until the central server says otherwise. The guest enters a username and password or a voucher code and submits it.
6.2 Request Forwarding by Router or Access Point
The router or access point that the guest connected to now acts as the network access server. This term simply means the device that stands between guests and the network and passes login requests to the central server. It takes the details the guest typed and forwards them as a request to the RADIUS server.
The captive portal is the login page that appears when a guest joins the hotspot. It collects the details, and the router or access point carries them onward. The router or access point does not judge the details itself. It only forwards them and waits.
6.3 Approval Response and Session Start
The central server checks the request and replies. If the guest is approved, the reply carries the session approval response, which includes the rules for that guest. The router or access point reads it, opens access, and begins the session. The start of the session is also the point where accounting begins to record activity.
Approved access begins only after central approval. Until the reply arrives, the guest stays on the login page. If the answer is a rejection, the guest is asked to try again, as described earlier.
7. Why Hotspot Operators Use Centralized RADIUS
Operators choose centralized RADIUS because it gives them one place to manage many guests, one set of rules, and control over sessions. A single RADIUS server takes on all three jobs. RADIUS authentication confirms identity, RADIUS authorization applies the rules, and RADIUS accounting records what happened. This is centralized hotspot login management in practice. Operators comparing approaches may want to look at RADIUS authentication for hotspots as a next step.
7.1 Managing Many Users From One Place
With a central server, an operator creates and manages guest details once. There is no need to visit each router to add a guest, remove a guest, or change what a guest is allowed to do. The same applies to voucher codes, which can be issued and checked in one place. As the number of users grows, the workload does not grow with each new device, which is the main advantage over creating separate accounts on each device.
7.2 Applying Consistent Access Rules Across Locations
Many operators run more than one location, or more than one router within a location. Consistent rules matter because guests expect the same experience everywhere. When rules live in the central server, every router and access point asks the same place and receives the same kind of answer.
A guest’s profile, duration rules, and limits apply no matter which device they reach. A rule change made once reaches every location at the next login, which avoids the mismatch that comes from editing devices one at a time.
7.3 Disconnecting Expired or Misused Sessions
Sessions should not last longer than they are meant to. An expired session disconnect happens when a guest’s allowed time ends and the access is closed. Central control makes this simpler because the same server that set the limits also knows when they are reached.
The same idea helps when a session is misused, for example when a login is shared more widely than intended. Because accounting records show what is happening, an operator can spot the problem and end the session from the center instead of working device by device.
8. How RADIUS Works With Hotspot Routers and Access Points
RADIUS is only one half of the picture. The other half is the hotspot hardware that guests actually connect to. Routers and access points carry the guest’s traffic, show the login page, and consult the RADIUS server. This section covers the role of the network access server, the shared secret that lets the devices trust each other, and the captive portal login that guests see. Operators who run hotspot routers may also want to look at a MikroTik hotspot billing system as a next step.
8.1 Role of the Network Access Server
The network access server is the router or access point that guests connect to. Its job is to forward login requests to the RADIUS server and then enforce whatever decision comes back. If the server approves a guest, the device lets them through with the rules from the approval. If the server rejects a guest, the device keeps them out.
In other words, the network access server is the enforcer and the RADIUS server is the decision maker. Neither can do the other’s job.
8.2 Shared Secrets and Trusted Communication
A shared secret is a trusted key that both the network access server and the RADIUS server know. It lets them trust each other. When a request arrives, the server can tell it came from a device it recognizes, and the device can tell the reply came from the real server. Without it, anyone could pretend to be either side.
The shared secret should be kept private, much like a password held between two devices. This article does not cover how it is set up.
8.3 Captive Portals and Login Pages
Captive portal login is the step where a guest sees a login page before access is approved. The captive portal is the page itself, and captive portal pages are the screens a guest meets when they join the hotspot.
At a conceptual level, the portal catches the guest’s first attempt to go online, shows the login page instead, and collects the details. Those details are then passed to the network access server and onward to the RADIUS server. Once the approval returns, the portal steps aside and the guest can continue online.
9. Operational Points to Understand Before Deployment
A central system is powerful, but it also becomes something guests and operators depend on. Three plain points are worth understanding before relying on it. They are server availability and failover, log accuracy together with time synchronization, and credential handling. Each is explained here in general terms, with no setup steps or settings.
9.1 Server Availability and Failover Behavior
Because every login decision comes from the central server, server availability and failover matter. Availability means the server is up and reachable when a router or access point needs it. Failover means a backup is ready to take over if the main server stops responding.
It helps to understand what happens when RADIUS server is unreachable. In general terms, the router or access point cannot get an answer, so new logins may not be approved until the server comes back or a backup takes over. How a particular setup behaves depends on how it was planned, which is why availability planning matters before guests rely on the hotspot.
9.2 Log Accuracy and Time Synchronization
Accounting records are only as good as their details. Log accuracy means entries correctly describe what happened. Time synchronization means the server and the routers or access points share the same view of the current time.
When both are in good shape, start and stop entries line up, session lengths make sense, and review is reliable. When they are not, records can contradict one another and make support questions harder to settle.
9.3 Credential Handling and Access Control
Credential handling means taking care of the details that prove identity or protect the system. That includes guest passwords, voucher codes, the shared secret between devices, and the administrative access operators use to manage the central server.
Access control means deciding who may manage the system, and it matters as much as deciding which guests may connect. In general terms, share these details only with people who need them, avoid passing them around casually, and limit administrative access to trusted people. Treat codes and secrets the way you would treat keys to the building.
10. FAQ
10.1 What does RADIUS stand for?
RADIUS stands for Remote Authentication Dial In User Service. Its role in central login management is to let routers and access points ask one central server whether a guest may connect.
10.2 What is the difference between authentication, authorization and accounting?
Authentication confirms who a user is. Authorization controls what an approved user can do. Accounting records session activity so it can be reviewed later.
10.3 Why use RADIUS instead of storing users on the router?
Storing users on each router creates separate local device accounts that must be updated one device at a time. With RADIUS, the records and rules sit in one central place, so changes are made once and every router follows them. This is easier to maintain as users and routers increase.
10.4 Does RADIUS provide internet access by itself?
No. RADIUS handles login decisions and records. Routers and access points provide the connection itself.
10.5 What happens if the RADIUS server is unreachable?
In general terms, the router or access point cannot get a login decision, so new logins may be held up until the server is reachable again or a backup takes over. This is why availability planning matters.
10.6 Can RADIUS work with voucher based hotspot logins?
Yes. RADIUS can work with voucher based hotspot logins. The voucher code acts as a temporary credential that the central server checks and then approves or rejects, just like any other login.