Hi Karl, Thanks for the proposal.
I feel call out as a party by the proposal as we, AWS, publish such list of IP Ranges for implementers to implement this at their perimeter layer. This becomes more complex as implementers on such platform can also bring their own CIDR for their IPAM (BYOIP). So there are times when it can be a list publicly published through an URI AND a CIDR non published that could act as expected networks. This seems to point at changing how implementers are deriving network controls from their IPAM. Therefore, Implementers on such platform would generally offload this kind of configuration to the layer 3 as they know from where the traffic is expected and need such guardrail in the protection of their endpoints whatever related to OAuth or not. As we discussed in Vienna, external information influencing authorization decision can lead to confusion on the server side. What should happen if the client is notifying client_ip_ranges": [ "198.51.100.10/32"] while the server has information on its side (maybe risk engine, Shared Signals Framework) that this IP is now flagged as malicious? Section 4.5.1 makes this worse: "After a failure, the authorization server MAY continue to use the accepted IP range set, within its retention limit, if it sets one." As the CONTOSO authorization server, I can't keep trusting old ranges because: * I can't retrieve the Atlassian ranges that ACME Corp (owner of a client hosted on Atlassian) publishes, or * ACME Corp doesn't keep up with Atlassian's changes and lets its document go stale. Section 4.3 also says "An accepted IP range set replaces the previously accepted IP range set in full." The draft already admits elsewhere that the server makes this decision: * Section 7.2 relies on backend policy controls. * Section 4.5.2, "Enforcement is relaxed after a withdrawal only by an explicit local policy decision," leaves the decision to admit an origin with the server. That sentence should be a MUST, to match the MUST NOT before it. If admitting an origin is a server-side decision, the spec should say so in 4.3 and treat the declaration as an input, not a replacement. But is this input trustable? The Client can mostly talk for itself from where it will come from and how much it should be trusted, but it has no authority on what the server should consider as legit origin. A client cannot infer that the rest of the hosts on the same CIDR and if they are as secure / legit as it is. Finally, can a client always know which IP the authorization server will see? NAT on the client side or the server side is common, and X-Forwarded-For can be scrubbed along the way. As 7.6 notes, X-Forwarded-For can only be trusted when a trusted party sets it. That means a trusted party has already checked the origin, which is where we should filter bad traffic anyway: as early as possible. I agree we each own our threat model. But the privacy considerations in Section 8 added to the fact that IPAM process are largely accepted in enterprise, are what make me most reluctant to standardize this. As you wrote it, the public range document exposes the client's egress infrastructure, and fetching it tells the host which authorization servers the client talks to. That is too much of a privacy nightmare for a problem that has already mitigation process in place. Jeff From: Karl McGuinness <[email protected]> Sent: October 28, 2026 2:54 PM To: [email protected] Subject: [EXT] [OAUTH-WG] New draft: OAuth Client IP Range Metadata (draft-mcguinness-oauth-client-ip-ranges-00) CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque. 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]
