I don't think this should go ahead. IP address-based access restrictions are a legacy security mechanism with questionable security benefits, particularly in modern cloud environments where addresses are frequently shared, reassigned, or changed.
In my experience over the past decade, these restrictions have caused far more operational problems than they have solved. I've seen organisations forced into convoluted traffic routing architectures, locked into expensive service provider arrangements, and subjected to significant troubleshooting complexity, all to satisfy IP allowlisting requirements. Some parts of the IETF have already recognised this problem. The webbotauth charter explicitly identifies IP allowlisting as having "significant limitations regarding security, scalability, and manageability" and sets out to develop cryptographic authentication mechanisms instead. While the use cases differ, the underlying problems with relying on IP addresses are much the same. I appreciate that the proposal aims to simplify managing existing IP allowlists. However, I'm concerned that standardising this mechanism would legitimise and encourage further deployment of a security practice we should instead be moving away from. -yaroslav On Wed, Oct 28, 2026 at 8:54 PM Karl McGuinness <[email protected]> wrote: > Hi all, > > Xiaoyi Zhang and I have submitted a new individual draft, OAuth Client IP > Range Metadata: > > https://datatracker.ietf.org/doc/draft-mcguinness-oauth-client-ip-ranges/ > > Many hosted OAuth clients send token requests from a known set of egress > addresses. Enterprises often choose to restrict their token endpoints to > those addresses, but today the ranges come from vendor-specific lists, each > in its own format. For example, Atlassian publishes IP ranges, including > egress ranges, at https://ip-ranges.atlassian.com/. Administrators must > translate these lists into local allowlists and keep them updated. > > A standard way to declare these ranges is particularly useful with OAuth > Client ID Metadata Documents, where clients can interact with an > authorization server without prior registration. Declaring ranges in client > metadata lets the authorization server obtain them directly. > > The draft defines two client metadata parameters, following the jwks/ > jwks_uri pattern: > > - client_ip_ranges: IPv4 and IPv6 prefixes by value > - client_ip_ranges_uri: an HTTPS URL of a JSON document with the > prefixes, for large or frequently changing sets > > The parameters can be conveyed through Dynamic Client Registration and > Client ID Metadata Documents, including in software statements. > > The draft also covers: > > - how authorization servers validate and accept declared ranges under > local policy; > - how retrieval failures and declaration withdrawal preserve existing > restrictions; > - recommended limits on retaining outdated sets. > > Declared ranges are an input to network access control. *They don't > replace client authentication or sender-constrained tokens.* > > Editor's copy: > https://mcguinness.github.io/draft-mcguinness-oauth-client-ip-ranges/draft-mcguinness-oauth-client-ip-ranges.html > Repository: > https://github.com/mcguinness/draft-mcguinness-oauth-client-ip-ranges > > Feedback on the approach and deployment use cases would be welcome, on the > list or in the repository. > > Thanks, > Karl > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- This communication (including any attachments) is intended for the sole use of the intended recipient and may contain confidential, non-public, and/or privileged material. Use, distribution, or reproduction of this communication by unintended recipients is not authorized. If you received this communication in error, please immediately notify the sender and then delete all copies of this communication from your system.
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
