ipauth
all systems live
Sign in
articles / roving access for invited users

Roving access for invited users.

You want one specific person, a contractor, a customer, an engineering lead, to reach something behind your firewall or CDN. Not the public, not a whole team, just them. And you do not want to repaste their IP every time they move.

The problem

Granting access to a single outside person is an awkward size. Opening the resource to the internet and relying on a login turns a private thing into a public one with a password in front of it. Pasting their current IP into a firewall or CDN rule works exactly once, until they switch from office to home to a client site, and then you are back in the dashboard editing allowlists by hand. The effort is small but constant, and it always lands on you, not them.

Why it matters

Outside access is where quiet exposure creeps in. A "temporary" public rule that never gets removed. A shared credential that outlives the engagement. An allowlist entry for an IP that was reassigned to someone else months ago. The cost is not one big breach; it is the slow accumulation of access you have lost track of. Per-person, self-maintaining, auditable access keeps that ledger clean.

How teams handle it today

How IPAuth does it

Create a named pair for each person and email them their auth URL; they bookmark it and click it whenever they move. Bundle their pairs into an access group. The group exposes one stable endpoint, a plain-text list of the current IPs of everyone in it. Your own sync script polls that endpoint every couple of minutes and rewrites your downstream allowlist (firewall, CDN, WAF, cloud security group) to match, replacing the previous set so nothing stale lingers.

Add or remove a person in the dashboard and the edge follows on the next sync; you never touch the script. Every action is recorded in an audit log, so "who has access and when did that change" has a real answer. The resource stays default-deny to everyone whose live IP is not currently in the group.

Where it fits, and where it does not

This is built for a known set of named individuals reaching IP-gateable resources. It binds access to network location, not to a verified human identity, so it pairs well with an existing credential when you need both factors. For anonymous, large-scale, or identity-proofed access, reach for a full IdP. For "these specific people, revocable per person, without me babysitting IPs," access groups are the lightest tool that does the job.

Set up an access group

Name a pair per person, bundle them, and point your sync script at the group's IP endpoint.

Create a group Setup for all OSes Back to use cases