Feature Suggestion/Request: Support for Dynamic IP Allowlisting

[danielmmetz]

Motivation

Some self-hosted apps are intended for access from devices that may lack oauth-flow capabilities (e.g. smart TV clients). An alternative means to permit access to a limited set of clients can be IP allowlisting. And to handle changing IPs (like one might experience while traveling), it's a nice to have if the IPs can be managed dynamically and with an expiry policy.

Proposal

Support a dynamic IP allowlist for auth bypasses.

Description of features

This is intended to be an illustrative example. Of course the implementation, if the proposal is accepted, could differ.

As an ordinary user, I can:

• visit a page to list any IP bypasses I own
• on that page, add a bypass for the IP associated with my current connection for an allowlisted set of domains (as configured by OIDC claim)
• on that page, delete a bypass I own

As an admin user, I can:

• visit a page to list all IP bypasses
• add a bypass for any IP address (or CIDR block) for any domain (or *) and set any user as the bypass owner
• delete any bypass

When a request comes in, it goes through the existing flow. Checking if a request matches one of these dynamic bypasses is just slightly more involved than the existing static IP bypass feature, but slots in very similarly.

Storage and TTLs

Sqlite table(s) can be added to record the bypass rows. A job can be added to the existing periodic worker to delete expired rows.

Functional Example:

I've already built this for myself atop v4.1.0. You can see it here (or here in diff form).

Here are some of the docs that could be incorporated into the docs website.

And below is a screenshot:

Next Steps

If this is of interest to you, I'd be happy to work with you to upstream it. Just let me know how you'd most like me to help in that case.

[steveiliop56]

Hello @danielmmetz,

The UI draft does indeed look nice. I am not so sure if we should include an admin UI though. Because then we would also need to start implementing features such as #620 and Tinyauth starts becoming not so easy to understand and use. If the community would like something like this though, we could attempt to implement a simple admin-like UI in the most minimal way possible.

[danielmmetz]

Very fair. Would you be interested in an API-only version of this in the meanwhile? If so, I'm happy to split apart the changes and put up a PR.

I'd also of course very much understand if you'd rather not, or if you'd rather generally hold-off if or until the minimal admin panel is further iterated.

[steveiliop56]

I suggest not for now. If we add the API paths we might as well add the UI so, let's just wait a bit. I would like to finalize some other features first and this specific one is not a priority for now.