WebAuth (web authentication)
termStands for: Web-based network authentication: the browser login a switch or controller forces before a port or wireless session is opened
Web authentication: the switch or controller feature that intercepts a new client's first browser request, serves a login page, checks the credentials against a RADIUS server and only then opens the port or session, for people on devices that cannot do 802.1X.
Cisco's Catalyst 9300 security guide describes the feature, "known as web authentication proxy", as the way "to authenticate end users on host systems that do not run the IEEE 802.1x supplicant". The sequence is the one every hotel guest has met: "The user initiates an HTTP session", "the HTTP traffic is intercepted, and authorization is initiated. The switch sends the login page to the user", the credentials go to the authentication server, and "if the authentication succeeds, the switch downloads and activates the user's access policy from the authentication server"; on failure the switch serves a fail page, and after the maximum number of attempts "the switch sends the login expired page, and the host is placed in a watch list". The guide describes the switch as "an intermediary (proxy) between the client and the authentication server", detects hosts by ARP and DHCP snooping, and states a limit that explains much modern grief: "HTTPS traffic interception for central web authentication redirect is not supported." The IETF's answer to interception, RFC 8952's captive portal architecture with the DHCP and router advertisement options of RFC 8910, is the standards side; the captive portal entry has the user's view. In the fallback order of a port, web authentication comes after 802.1X and MAB.
Web authentication is the third way onto an authenticated port, after 802.1X for devices with a supplicant and MAC Authentication Bypass for things on a list, and it is the one built for people: a visitor with a laptop that has no supplicant configured, a contractor on a personal device, a student on a campus network. Cisco's Catalyst 9300 security configuration guide, in its chapter on configuring web-based authentication, says to use the feature, "known as web authentication proxy, to authenticate end users on host systems that do not run the IEEE 802.1x supplicant". The design is a man-in-the-middle performed by the network on purpose: the switch sits between the browser and the authentication server and, in the guide's words under Device Roles, "acts as an intermediary (proxy) between the client and the authentication server, requesting identity information from the client, verifying that information with the authentication server, and relaying a response to the client".
The sequence in the guide's Authentication Process section is the one a user experiences as a login page appearing from nowhere. "The user initiates an HTTP session"; "the HTTP traffic is intercepted, and authorization is initiated. The switch sends the login page to the user"; the user enters credentials, which the switch sends to the authentication server over RADIUS; "if the authentication succeeds, the switch downloads and activates the user's access policy from the authentication server" and shows a success page. On failure "the switch sends the login fail page. The user retries the login. If the maximum number of attempts fails, the switch sends the login expired page, and the host is placed in a watch list." The four pages, Login, Success, Fail and Expire, are customisable, and a Local Web Authentication Banner can carry an organisation's text or logo on the login page and the result pop-ups. Before any of that can happen the switch has to notice the host, and the guide lists the triggers for a Layer 2 port: an ARP-based trigger that catches hosts with static or dynamic addresses, dynamic ARP inspection, and DHCP snooping, which notifies web authentication when a binding is created. The session is re-authenticated when a host on a Layer 2 interface stops answering ARP probes, or when a host on a Layer 3 interface sends nothing within the idle timeout.
The mechanism's dependence on interception is also its decline, and the guide states the limit without softening: "HTTPS traffic interception for central web authentication redirect is not supported." A browser whose first request is an HTTPS one, which is now most browsers' first request, cannot be redirected without a certificate warning, and the same is true of applications with pinned certificates and of encrypted DNS. The IETF's response was to stop pretending. RFC 8952, Captive Portal Architecture, of November 2020, describes an architecture of user equipment, a provisioning service, a captive portal API server, an enforcement device and a captive portal signal, in which the network tells the device, rather than tricks it, that a portal exists; it states that "solutions MUST NOT require the forging of responses from DNS or HTTP servers". RFC 8910, of September 2020, gives the network the means: DHCPv4 option 114, DHCPv6 option 103 and router advertisement option 37 carry the URI of the captive portal API, replacing a deprecated option 160 that had misbehaved in the field. Operating systems that implement this learn of the portal at address assignment and open it themselves. The captive portal entry describes the user-side view of the same history.
In enterprise deployments the names matter. Local web authentication is the feature described above, with the switch or controller serving the pages; central web authentication moves the portal to the policy engine, with the switch redirecting to it and the engine returning the authorisation, usually with a RADIUS Change of Authorization once the user has logged in, which is the configuration the HTTPS limit above is about. Either way the identity established is a person's, checked against the same RADIUS servers and directories as everything else, and the authorisation that follows should be the visitor's, a VLAN or a filter that reaches the Internet and nothing internal.
The fallback order on a port is the design summary: 802.1X first, because it authenticates the device with a credential; MAB second, for the things on a list; web authentication third, for the people on devices that can do neither. The 802.1X and MAB entries cover the first two, and the article on web authentication and captive portals sets the enterprise feature beside the standards that are replacing interception.
Also known as: web authentication, web-based authentication, web authentication proxy, central web authentication, local web authentication, guest portal
Sources
- Cisco Catalyst 9300 IOS XE 17.9 Security Configuration Guide, Configuring Web-Based Authentication: the web authentication proxy for hosts without an 802.1X supplicant, the intercepted HTTP session and the login page, the policy downloaded on success, the fail and expired pages and the watch list, host detection by ARP and DHCP snooping, the HTTPS interception limit (read 2026-10-06)
- RFC 8952, Captive Portal Architecture, Larose (Agilicus), Dolson, Liu (Google), November 2020, Informational: the components, provisioning by DHCP or RA and the API, the ban on forging DNS or HTTP responses, and what the architecture does not do (read 2026-10-06)
- RFC 8910, Captive-Portal Identification in DHCP and Router Advertisements, Kumari (Google) and Kline (Loon), September 2020, Standards Track: DHCPv4 option 114, DHCPv6 option 103, RA type 37; the URI of the captive portal API; option 160 deprecated (read 2026-10-06)