Summary

  • The 28 October individual Internet-Draft proposes two mutually exclusive OAuth client metadata fields: client_ip_ranges carries IPv4/IPv6 prefixes directly; client_ip_ranges_uri points to an HTTPS JSON document. Registration or retrieval of a list is separate from the authorization server's acceptance of that list.
  • A failed fetch, invalid update or withdrawal cannot silently widen access. The server may retain the old accepted set, narrow it against a pending replacement, and set a retention limit. When that limit expires, an enforcing server rejects client requests until a current set is accepted or an explicit local decision removes enforcement.

A new address is a request, not a hall pass

A hosted client moves its outbound traffic to a new cloud range on Friday. Its operator edits a JSON file, and the authorization server fetches it. The file is fresh. The client is still stuck outside the token endpoint if the server has not accepted the new range. The draft makes that separation deliberate: a successful registration of metadata or HTTP retrieval does not promote a prefix into the accepted set. The server decides whether an expansion fits its local policy.

The client has two ways to make its declaration. It can put prefixes directly in client_ip_ranges, or give an HTTPS client_ip_ranges_uri for a separately fetched document. It cannot present both. No field means no declaration; an empty array means an empty set. That distinction matters when updating a client under RFC 7592: the draft says an empty array is a deliberate declaration, not an instruction to delete the field. A server enforcing the accepted empty set admits no source address.

The server validates the whole proposed set and accepts it as a replacement, not a stream of incremental edits. It may narrow its current set to the intersection with a validated replacement while approval is pending. That lets an operator close an old exit before opening a new one. The client is advised to add a new prefix before traffic moves and keep the old prefix until traffic has actually left it. The scheduling is operational: a document can be retrieved in the background, and approval can take longer than HTTP refresh.

An unavailable document does not turn an allowlist into an open door. Failed retrieval, malformed content and invalid metadata cannot cause admission of an address previously blocked. Withdrawal of the declaration has the same boundary; relaxing enforcement takes an explicit local decision. The server should put a limit on how long it carries an old accepted set through failure, withdrawal or an unaccepted replacement. Once that clock runs out, an enforcing server rejects the client's requests until it accepts a set under the current declaration or explicitly ends enforcement.

Rechecking an unaccepted replacement does not restart that clock.

The old set has a cost of its own. Addresses can change hands. If a stale accepted range is reassigned, the server may still admit packets from it. The draft's intersection option and retention limit address that exposure. RFC 9111 explains HTTP cache behavior, but the draft calls the accepted range separate application state: a fresh 304 Not Modified is not a policy vote, and expiry of a cached response is not automatic revocation.

The declaration is also narrower than identity. A firewall in front of the token endpoint sees source addresses but not which OAuth client sent them; it can enforce only an aggregate. The authorization server can apply a per-client set after identifying the client. A matching IP does not authenticate the client. A software statement that signs the document URL vouches for that URL, not for whatever the host later serves there. The document host therefore has power over availability as well as the address list.

The IETF record lists an individual proposal, with no reported deployment. A real migration test should show the fetched version, accepted set, approval time, old-range retirement and token-endpoint decisions before and after the move. Those receipts would reveal who actually controlled the gate.

Sources: individual draft; IETF status; RFC 7592; RFC 9111.