]> Independent

public@karlmcguinness.com

Databricks

xiaoyi.zhang@databricks.com

Security Web Authorization Protocol OAuth client metadata IP address network access control This specification defines OAuth client metadata parameters for declaring the IP address ranges from which a client originates network requests. The client_ip_ranges parameter carries a set of IPv4 and IPv6 prefixes by value. The client_ip_ranges_uri parameter references an HTTPS resource containing the set, so that large and frequently changing sets can use standard HTTP retrieval and caching. The specification also defines how authorization servers validate, accept, and retain declared ranges. The parameters can be used with OAuth 2.0 Dynamic Client Registration, OAuth Client ID Metadata Documents, and other mechanisms that convey client metadata. Authorization servers and other parties that obtain a client's metadata can use the declared ranges as an input to network access control. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction OAuth clients that run as hosted services commonly originate requests from a known set of network addresses. Authorization servers, resource servers, and the network infrastructure in front of them use these addresses to restrict which sources can reach the token endpoint and protected resources. In current practice, client operators publish their address ranges through vendor-specific mechanisms, and deployments transcribe them into network access controls by hand. Clients that use OAuth Client ID Metadata Documents can reach authorization servers without prior registration, leaving no opportunity to exchange ranges by hand in advance. Client metadata () has no parameter for the network origins of a client. This specification defines two client metadata parameters that declare the IP address ranges from which a client originates requests: client_ip_ranges, which carries the ranges by value, and client_ip_ranges_uri, which references a Client IP Range Document that contains them. As with the jwks and jwks_uri parameters of , the two forms have the same semantics and are mutually exclusive. The reference form lets a client publish a large or frequently changing set without updating its registration. The parameters can be used with OAuth 2.0 Dynamic Client Registration , OAuth Client ID Metadata Documents , and other mechanisms that convey client metadata. Declared ranges are an input to network access control. Deployments use source address restrictions to limit where a client's credentials and grants can be used. Declared ranges do not authenticate the client or authorize a request (). They complement client authentication and sender-constrained tokens (, ), which bind credentials and tokens to keys rather than to network locations. This specification defines the metadata and the processing requirements for authorization servers that use it. Other parties that obtain a client's metadata can apply the same processing. Selecting the clients subject to enforcement, approving declared ranges, and configuring network enforcement points are local policy; describes typical deployments. Enforcement by resource servers is outside the scope of this specification.

Requirements Notation and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology This specification uses the terms "access token", "authorization server", "client", "client authentication", "protected resource", "resource owner", "resource server", and "token endpoint" defined by OAuth 2.0 , and the terms "client metadata" and "software statement" defined by OAuth 2.0 Dynamic Client Registration . This specification defines the following terms:

IP range set:

The set of IPv4 and IPv6 prefixes that a client declares, either by value with client_ip_ranges or by reference with client_ip_ranges_uri.

Client IP Range Document:

A JSON document, defined in , that contains an IP range set and is referenced by client_ip_ranges_uri.

client IP range metadata:

The client_ip_ranges and client_ip_ranges_uri client metadata parameters.

accepted IP range set:

The IP range set, if any, that an authorization server has validated, accepted, and currently uses for a client, possibly narrowed ().

Client IP Range Metadata This specification defines the following client metadata parameters () for declaring the IP address ranges from which a client originates requests ():

client_ip_ranges:

OPTIONAL. JSON array of strings, each an IPv4 or IPv6 prefix (). The array is a set. The authorization server MUST NOT assign meaning to the order of entries or to duplicate entries. An empty array declares an empty IP range set.

client_ip_ranges_uri:

OPTIONAL. URL of a Client IP Range Document () that contains the client's IP range set. The URL MUST use the https scheme and MUST NOT contain a fragment or userinfo component . The authorization server retrieves the document as described in .

The client_ip_ranges and client_ip_ranges_uri parameters MUST NOT both be present in the same client metadata. If neither is present, the client makes no declaration, which differs from declaring an empty IP range set. This specification sets no maximum number of entries; the authorization server applies its own bounds ().

Prefix Syntax Each prefix MUST conform to the ip-prefix type defined in , that is, match in full every pattern of either the ipv4-prefix or the ipv6-prefix type. A value that does not conform is invalid. The client, and the party hosting a Client IP Range Document, MUST represent each prefix in the canonical format of that type, with all bits outside the prefix length set to zero and, for IPv6, the address represented as defined in . A value that is not in canonical format is nonetheless valid and denotes the prefix given by its network address and prefix length (). For example, 192.0.2.1/24 denotes 192.0.2.0/24, and 2001:DB8::1/64 denotes 2001:db8::/64. A prefix within the IPv4-mapped IPv6 address range ::ffff:0:0/96 () is invalid; IPv4 ranges are expressed as IPv4 prefixes. Every prefix length that the ip-prefix type permits, including zero, is valid. Whether to accept a broad prefix is local policy ().

Metadata Validation If a trusted software statement () carries client_ip_ranges or client_ip_ranges_uri, the authorization server ignores both parameters elsewhere in the client metadata, whether in a registration request or in a Client ID Metadata Document (). This extends the precedence rule of to the pair of parameters. After this precedence is applied, client IP range metadata is invalid if any of the following is true:

1. Both client_ip_ranges and client_ip_ranges_uri are present.
2. The value of client_ip_ranges is not an array of strings, or any entry is an invalid prefix ().
3. The value of client_ip_ranges_uri does not meet the requirements of .
4. The value of client_ip_ranges has more entries than the authorization server's bound on prefixes ().

If a client registration request, or a client update request (), contains invalid client IP range metadata, the authorization server responds with an HTTP 400 (Bad Request) error response as described in , using invalid_client_metadata as the error code value, or invalid_software_statement if the invalid value comes from a trusted software statement. The authorization server MUST NOT substitute a default value for invalid client IP range metadata. If a Client ID Metadata Document contains invalid client IP range metadata, the authorization server handles this as a validation failure () without treating the rest of the document as invalid. An authorization server that does not support these parameters ignores them (). The client information response () shows whether the authorization server registered them.

Client IP Range Document A Client IP Range Document is a JSON object with the following member:

client_ip_ranges:

REQUIRED. JSON array of prefixes, with the same syntax and semantics as the client_ip_ranges client metadata parameter ().

The authorization server MUST ignore members that it does not understand. A document whose top-level object contains duplicate member names is invalid; notes that receivers handle such objects unpredictably. The document is self-contained, and the authorization server MUST NOT retrieve other resources to complete it. Multiple clients can reference the same document; all its prefixes apply equally to each such client. The document can be hosted by a party other than the client, such as its hosting provider. The following is a non-normative example of a Client IP Range Document:

Retrieval and Acceptance

Retrieval An authorization server retrieves a Client IP Range Document by sending an HTTP GET request to the client_ip_ranges_uri URL, subject to . A response is successful if it has status code 200 (OK), the application/json media type, and a complete body within the authorization server's bounds (), or if it has status code 304 (Not Modified) () in answer to a conditional request (). Following a 304 response, the authorization server MUST apply the same response and document validation requirements to the corresponding stored response, with its header fields updated as described in . A 304 response for which the authorization server has no corresponding stored response is a failure. The party hosting a Client IP Range Document MUST serve it with the application/json media type and MUST NOT require authentication to retrieve it unless that party and the authorization server have agreed on an authentication mechanism, which is outside the scope of this specification. The authorization server MUST NOT send credentials associated with an OAuth request, such as client credentials, access tokens, or authorization codes, when retrieving the document. The authorization server MUST NOT treat a failed retrieval, an unsuccessful response, or an invalid document as an empty IP range set; each is a failure ().

Caching The party hosting a Client IP Range Document SHOULD support HTTP caching and SHOULD include the Cache-Control () and ETag () response header fields. The accepted IP range set is application state, distinct from any HTTP cache (). A fresh response does not make its IP range set accepted, and expiry of a cached response does not end use of the accepted IP range set (). The authorization server SHOULD retrieve the document periodically to obtain changes.

Acceptance Before accepting an IP range set, the authorization server MUST ensure the following:

1. The client IP range metadata that conveys the set is valid (), and every prefix in the set is valid ().
2. If the set was obtained from a Client IP Range Document, the response is successful () and the complete document is valid ().

If any of these checks fails, the authorization server MUST reject the entire set. Acceptance is also subject to local policy (). Registering client IP range metadata does not by itself accept its IP range set. An accepted IP range set replaces the previously accepted IP range set in full; this specification defines no incremental update format. The accepted IP range set remains in effect until the authorization server accepts a replacement, narrows it, or stops using it (). While a validated replacement awaits acceptance, an authorization server MAY narrow the accepted IP range set to its intersection with the replacement, so that it admits only source addresses that both sets match. The narrowed set remains the accepted IP range set; the replacement is still not accepted. A client SHOULD add a prefix to its IP range set before it originates requests from addresses in that prefix and SHOULD keep the prefix in the set until it no longer originates requests from them.

Changes to Client Metadata A client's metadata can change the value of client_ip_ranges_uri, switch between client_ip_ranges and client_ip_ranges_uri, or remove both. The new metadata replaces the previous declaration. When the metadata changes representation or URL, the accepted IP range set remains in effect as described in . An invalid new declaration in a Client ID Metadata Document, or an unretrievable or invalid new document, is a failure (). If the previous metadata contained client_ip_ranges_uri, the authorization server MUST NOT retrieve that URL for the client while the client's current metadata does not reference it. Removal of both parameters withdraws the client's declaration (). In a client update request (), omitting both parameters requests their removal, which the authorization server can ignore. An empty client_ip_ranges array is different: unlike other empty values in an update request (), it declares an empty IP range set, and the authorization server MUST NOT treat it as a request to delete the parameter or ignore it. The client information response () shows whether the parameters were removed.

Retention

After a Failure A failure to retrieve a Client IP Range Document, or to validate client IP range metadata or a retrieved document, MUST NOT cause an authorization server to admit a source address that it did not admit before the failure. After a failure, the authorization server MAY continue to use the accepted IP range set, within its retention limit, if it sets one ().

After a Withdrawal Withdrawal of the client's declaration () MUST NOT by itself cause an authorization server to admit a source address that it did not admit before the withdrawal. Enforcement is relaxed after a withdrawal only by an explicit local policy decision.

Retention Limit An authorization server SHOULD set a retention limit on how long it continues to use an accepted IP range set in any of the following cases ():

• while retrieval or validation of the client's current declaration fails;
• after the client withdraws its declaration; or
• while a validated replacement has not been accepted under local policy.

The limit runs from the first failed retrieval or validation, from the withdrawal, or from the first validation of the replacement, and ends when the authorization server accepts a set under the client's current declaration. The limit for the first case also ends when a successful retrieval or validation, including one that ends in a 304 response, confirms that the accepted IP range set is current. Revalidating a replacement that has not been accepted does not restart its limit. The third case does not apply to an accepted IP range set that the authorization server has narrowed to its intersection with the replacement (), because every source address that set admits is also in the replacement. When the retention limit is exceeded, the authorization server stops using the set and has no accepted IP range set for the client ().

Enforcement The IP range set identifies source addresses from which the client originates requests directly to authorization servers and resource servers, such as token requests and requests to protected resources. It does not describe the network origins of user agents or of requests initiated by the resource owner. A source address matches an IP range set if it is within any of its prefixes. Before matching, the authorization server MUST convert an IPv4-mapped IPv6 source address to the IPv4 address it contains. An authorization server that enforces a client's accepted IP range set admits requests from the client only from source addresses that match it; if that set is empty, it admits none. While a client has no accepted IP range set:

• an authorization server that requires an accepted IP range set for the client MUST reject requests from the client;
• after the retention limit is exceeded (), an authorization server that was enforcing a set for the client MUST reject requests from the client until it accepts an IP range set under the client's current declaration or an explicit local policy decision removes the client from enforcement; and
• in other cases, what applies is local policy.

An authorization server MAY use the accepted IP range set as an input to local network access control. A match does not authenticate the client or authorize a request. The authorization server MUST NOT use a source address match in place of client authentication, access token validation, or any other security control required by OAuth. Enforcement by resource servers, including how a resource server determines the client associated with a request and obtains that client's metadata, is outside the scope of this specification and could be addressed by a companion specification.

Client Identification and Error Responses An authorization server can enforce a client's accepted IP range set at the token endpoint and at other endpoints that receive direct requests from the client, once it has identified the client, either through client authentication or, for a public client (), as the client to which a grant or token presented in the request was issued, such as an authorization code, a device code (), or a refresh token. At the client configuration endpoint, the registration access token identifies the client (). This specification does not define enforcement for a public client in a request that identifies the client only by an unauthenticated client_id, such as a device authorization request (). A request rejected because of its source address does not count as a use of the authorization code it presents (). In a response to a party that has not authenticated as the client, an authorization server SHOULD NOT indicate that a request was rejected because of its source address. This specification does not yet define the error response for a request rejected because of its source address ().

Implementation Considerations

Enforcement Points Enforcing the accepted IP range set of a specific client requires knowing which client sent a request. A network enforcement point that operates below HTTP, such as a firewall, observes the source address but not the client, so it can enforce only the aggregate of the IP range sets of the clients permitted to reach an endpoint. An authorization server can enforce each client's accepted IP range set once it has identified the client (). For example, an enterprise adds a hosted client's approved ranges to the network allowlist in front of its token endpoint, and the authorization server also enforces the client's accepted IP range set. Local policy determines whether later changes are accepted automatically or require administrator approval (). Deployments that require an accepted IP range set need an administrative recovery path for a client whose source addresses move outside that set, such as approving a replacement set. Enforcement at the client configuration endpoint () can prevent the client from updating a declaration made by value.

Retrieval Scheduling An authorization server can retrieve documents in the background rather than while processing an OAuth request, and typically schedules the next retrieval when the stored response's freshness lifetime () ends, within local minimum and maximum intervals. A client needs to allow for these intervals, and for approval delays, when adding a prefix (). To revalidate with If-None-Match (), an authorization server uses the entity tag of the most recent complete response it stored from that URL (), which can be newer than the one from which the accepted IP range set was derived.

Document Size recommends that authorization servers read at most 5 kilobytes of a Client ID Metadata Document. A client whose IP range set does not fit within such a limit can use client_ip_ranges_uri. An authorization server sets its bounds on Client IP Range Documents () independently of bounds on client metadata. The gzip content coding () can reduce the transfer size of large documents.

Security Considerations The security considerations of the mechanism that conveys the client metadata, such as or , also apply.

Trust in Declared Ranges Client IP range metadata is a declaration made by or on behalf of the client. Inclusion of a prefix does not establish that the client exclusively owns or controls the addresses it contains. Prefixes of shared infrastructure, such as cloud provider or carrier-grade NAT egress ranges, also carry traffic from other parties. Whether to use declared ranges in network access control is a local trust decision. A software statement () vouches only for the values it contains: for client_ip_ranges, the prefixes; for client_ip_ranges_uri, the URL but not the referenced document. The party hosting the document asserts its contents, and accepting them automatically is a separate decision to trust that party within an approved scope (). A malicious or compromised party hosting a document can also deny service to every client that references it, by publishing an empty or unrelated IP range set or by keeping the document unavailable beyond the retention limit. A client cannot observe whether an authorization server enforces its declaration, so declaring an IP range set does not by itself protect the client's credentials. An authorization server can require that client_ip_ranges_uri share an origin () with the client identifier URL of a Client ID Metadata Document .

Changes to Declared Ranges A change to a client's IP range set can broaden or narrow the source addresses admitted by a network policy derived from it. An authorization server MUST NOT treat the addition of a prefix to a client's IP range set as granting network access by itself. When local policy permits automatic updates for the client and the change falls within an approved scope, such as prefixes contained in supernets that the authorization server has configured for the client, the authorization server MAY accept the change automatically. Detecting unexpected expansion of a client's IP range set, including the addition of overly broad prefixes, helps an authorization server decide which changes to hold for approval. The authorization server SHOULD apply changes atomically, so that no intermediate state admits a source address that neither the previous nor the new IP range set contains. An accepted IP range set that no longer matches the client's current declaration can include addresses that have since been reassigned to another party. The retention limit () and narrowing () limit how long such addresses remain admitted.

Rejection Responses A rejection that a requesting party can attribute to its source address tells that party that its other inputs were acceptable. If the authorization server checks the source address only after client authentication succeeds, such a rejection confirms to a party holding stolen or guessed client credentials that they are valid. limits this disclosure for parties that have not authenticated as the client; what the error response discloses to authenticated parties is part of the open issue on that response ().

Server-Side Request Forgery Retrieval of client_ip_ranges_uri causes an authorization server to send a request to a URL supplied in client metadata, which creates a risk of Server-Side Request Forgery (SSRF) attacks. When retrieving a Client IP Range Document, the following requirements apply:

1. The authorization server MUST NOT retrieve a URL that does not meet the requirements for client_ip_ranges_uri in .
2. The authorization server MUST verify the server certificate as described in and MUST NOT accept a document retrieved over a connection that fails this verification. This strengthens the requirement of that section for automated clients.
3. The authorization server MUST NOT automatically follow HTTP redirects ().
4. The authorization server MUST NOT connect to an address that the IANA special-purpose address registries (, ) list as not globally reachable, unless local policy explicitly permits that destination. This check applies to the address of each connection after DNS resolution. An authorization server that retrieves through a configured forward proxy relies on the proxy to apply this check.

An authorization server retrieving a URL obtained from a Client ID Metadata Document is also subject to ; the local policy exception in item 4 does not override that section.

Resource Exhaustion A malicious or compromised party hosting a Client IP Range Document can return an oversized document, a highly compressed response, or a large number of overlapping prefixes. An authorization server MUST bound retrieval time, response size, decompressed size, and the number of prefixes in an IP range set, whether conveyed by value or in a document. If a document exceeds any bound, the authorization server MUST reject the entire document. This specification sets no minimum value for any of these bounds.

Source Address Interpretation Proxies, load balancers, and network address translation change the source address that an authorization server observes. The authorization server MUST determine the source address from a trusted source of connection-origin information. A source address that the authorization server cannot determine in this way matches no IP range set. The authorization server MUST NOT use a forwarding header field, such as Forwarded or X-Forwarded-For, as the source address unless it was set by an intermediary the authorization server trusts. Because a trusted intermediary can append its own observation to a field that already carries entries supplied by an attacker (), the authorization server MUST select the source address from such a field using its configuration of trusted proxies and MUST NOT trust an entry merely because a trusted intermediary forwarded or appended to the field.

Privacy Considerations Client IP range metadata describes network infrastructure rather than end users. However, when a client runs on infrastructure associated with an individual, such as a residential network, its declared ranges can reveal that individual's network location. A publicly retrievable Client IP Range Document, or a publicly retrievable Client ID Metadata Document that carries client_ip_ranges, discloses the client's egress infrastructure to any party. Retrieval of client_ip_ranges_uri reveals to the party hosting the document the addresses and retrieval timing of authorization servers that evaluate the client, which can indicate the authorization servers and resource servers with which the client is used (see also ).

IANA Considerations This specification requests registration of the following client metadata in the "OAuth Dynamic Client Registration Metadata" registry established by .

• Client Metadata Name: client_ip_ranges
• Client Metadata Description: Array of IPv4 and IPv6 prefixes from which the client originates requests
• Change Controller: IETF
• Specification Document(s): of this specification

• Client Metadata Name: client_ip_ranges_uri
• Client Metadata Description: HTTPS URL of a document containing the IPv4 and IPv6 prefixes from which the client originates requests
• Change Controller: IETF
• Specification Document(s): of this specification

References Normative References A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK] The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA. It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block. This memo updates the IANA IPv4 and IPv6 Special-Purpose Address Registries to address issues raised by the definition of a "global" prefix. It also corrects several errors in registry entries to ensure the integrity of the IANA Special-Purpose Address Registries. This memo updates RFC 6890. This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. This document defines a collection of common data types to be used with the YANG data modeling language. It includes several new type definitions and obsoletes RFC 6991. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK] This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request. This specification defines methods for management of OAuth 2.0 dynamic client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods. The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device. This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. Okta This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration. This is through the usage of a URL as a client_id in an OAuth flow, where the URL refers to a document containing the necessary client metadata, enabling the authorization server to fetch the metadata about the client as needed. Independent This document defines a standardized JSON format for operators of automated HTTP clients (e.g., web crawlers, AI bots) to publicly disclose their IP address ranges. A consistent, machine-readable format for IP range publication simplifies the task of identifying and verifying legitimate automated traffic, thereby decreasing maintenance load on website operators while reducing the risk of inadvertently blocking beneficial clients. This specification codifies and extends common existing practices to provide a simple yet extensible format that accommodates a variety of use cases.

Examples

Dynamic Client Registration by Value The following is a non-normative example of a client registration request () that declares an IP range set by value:

Client ID Metadata Document by Reference The following is a non-normative example of a Client ID Metadata Document that declares an IP range set by reference:

Document Retrieval The following is a non-normative example of a request for the Client IP Range Document referenced above: The following is a non-normative example of a successful response: The following non-normative example shows a later conditional request and a response indicating that the document is unchanged:

Related Work defines a format for publishing the IP address ranges of automated HTTP clients. Each prefix is an object with exactly one of an IPv4 or an IPv6 member and optional service identifiers, the document carries a creation time, and a prefix object that has both or neither address member is ignored. This specification instead uses the same prefix array in the Client IP Range Document as in client_ip_ranges, rejects the whole set when any prefix is invalid (), and relies on client metadata to associate the set with a client. Clients can announce planned changes to their IP range sets through a separately specified notification mechanism, such as event types delivered using the Shared Signals Framework . This specification does not define advance announcement events or scheduled activation of ranges.

Open Issues RFC EDITOR: Remove this section before publication.

1. Which error response indicates that an authorization server rejected a request under a client's source address policy? The invalid_client error code signals failed client authentication () and could prompt credential rotation, while an error that identifies the source address confirms to a party holding stolen credentials that they are valid ().

Document History RFC EDITOR: Remove this section before publication. -00

• Initial version.