Product Decisions This Supports
- Build vs. buy on AAA (Authentication, Authorization, Accounting). The decisive question is usually not "do we need RADIUS?" but "do we already have a RADIUS server (FreeRADIUS, Microsoft NPS, Cisco ISE, Telco NEP) and just need PHP to talk to it?" This package supports the cheap path: keep the AAA server your customers' network admins already trust, and add a client shim instead of standing up a competing auth stack. That's a one-sprint decision instead of a one-quarter one.
- Feature: "Bring your own identity provider" for network-facing products. If the roadmap includes ISP/broadband subscriber login, hotspot or captive-portal access, WPA2-Enterprise (802.1X) onboarding, VPN concentrator auth, or a managed-Service-Provider console, this library is the enabling dependency. It turns "we can't integrate with your existing network auth" from a lost deal into a configuration screen.
- Roadmap: usage-based billing and session control. RADIUS Accounting packets are the cheapest source of truth for connection start/stop, session duration, and byte counters in ISP, MVNO, hospitality Wi-Fi, and IoT-connectivity products. If the pricing model shifts toward metered or per-session billing, this is the ingestion mechanism. Related: CoA/Disconnect messages (RFC 5176) unlock "force logout / change plan mid-session / revoke access now" — a support-cost reducer that customers will notice.
- Use cases worth sizing: delegated authentication for enterprise tenants, per-session bandwidth metering for billing, MFA-via-RADIUS (OTP backends), and access revocation for offboarding. Each is a discrete roadmap item with a shared dependency.
- Architecture call: in-process client vs. sidecar. Choosing a pure-PHP client over shelling out to
radclient or standing up a Go/Rust auth microservice is a real PM-visible tradeoff — fewer moving parts and one deploy unit, at the cost of per-request UDP round-trips inside your request lifecycle. Decide once, document it, and don't let it be re-litigated per feature.
- Procurement, not just engineering. The LGPL-3.0 license and a single-maintainer project with ~83 stars and a low opportunity score mean this needs a legal review and an exit plan before it becomes load-bearing. That review is a gate on the roadmap item, not a footnote.
When to Consider This Package
Consider it when:
- You are a client, not a server — you need to authenticate a user or record a session against an existing RADIUS endpoint, and you have no intention of implementing AAA yourself.
- You need the standard method coverage — PAP, CHAP, MS-CHAPv1/v2, and the usual attribute dictionary handling — rather than exotic EAP variants.
- Your stack is a PHP/Laravel monolith and the team values deploy simplicity over raw throughput. Auth and accounting traffic in most SaaS products is low-QPS; a per-request UDP exchange is fine.
- You need accounting and CoA/Disconnect, not just login — that combination is unusually well served here relative to what else is on Packagist.
- Your integration target is a server your customers already run, so the library's job is protocol correctness and attribute fidelity, not product surface.
Look elsewhere when:
- You need to be the RADIUS server (listener, shared secrets per NAS, proxying, realms). This is the wrong side of the wire — go to FreeRADIUS, or wrap it via its REST/
rlm_rest module.
- You need RadSec/TLS, EAP-SIM/AKA/TTLS termination, or Diameter / 5G SBA interfaces — verify current support explicitly rather than assuming; these are the requirements most likely to disqualify the package late.
- You need vendor-backed SLAs, security advisories with a response commitment, or a support contract. Solitary-maintainer projects don't provide that, regardless of code quality.
- You are distributing a closed-source binary/appliance where LGPL-3.0 obligations become commercially awkward. Note that PHP's dynamic-inclusion model makes the "linking" analysis genuinely ambiguous — get counsel, don't self-assess.
- Latency budgets are tight and auth sits on the critical path of every request. A sidecar or a dedicated auth service with connection reuse and backoff will beat in-request UDP.
In all cases: wrap it behind your own narrow interface (an Authenticator / AccountingSink port) on day one, so the exit cost is a class swap rather than a refactor.
How to Pitch It (Stakeholders)
For executives (one paragraph): We have a recurring class of deals — ISPs, hospitality, enterprise IT, managed network services — that stall because we can't authenticate against the RADIUS server they already run. This is a small, mature, pure-PHP client library that lets us plug into that infrastructure instead of building or buying an AAA platform. The commercial effect is that we unlock network-facing segments with a dependency and a few weeks of integration rather than a multi-quarter platform investment, and it gives us session-level accounting data we can later monetize through usage-based pricing. Two caveats we're managing, not ignoring: the license is LGPL-3.0 and requires a legal sign-off before we ship it, and it's a single-maintainer open-source project, so we'll isolate it behind an internal interface to keep switching costs near zero.
For engineering: It solves the boring, error-prone part — packet encoding, attribute dictionaries, message-authenticator computation, response validation, retransmission — so we write product code instead of byte-twiddling. It covers the auth methods and accounting/CoA flows we actually need, and it's usable directly from Laravel's container. Adopt it behind an adapter interface, pin the version, add contract tests against a real FreeRADIUS container in CI, and treat the LGPL boundary and the maintainer bus factor as tracked risks with a documented fallback (radclient sidecar) if either degrades.