www-authenticate resource_metadata and query strings vs resource identifier #66
Description
If the protected resource metadata was retrieved from a URL returned by the protected resource via the WWW-Authenticate resource_metadata parameter, then the resource value returned MUST be identical to the URL that the client used to make the request to the resource server. If these values are not identical, the data contained in the response MUST NOT be used.
I believe this is going to be a big point of contention and the first thing implementers will forego validating because resource servers will not (be able to?) implement this correctly. Given the flow where a client hits a protected resource without authorization in order to obtain www-authenticate and then use resource_metadata it MUST validate that the resource value returned be identical to the URL the client was accessing. This means that the RS needs to host a discovery document for every single endpoint.
Now, given to a resourceful (pun intended) engineering team this is okay because the route handler for the "metadata" path will take the pathname without the well known prefix as a "parameter" and return that in its response as the resource and be able to, depending on the pathname, provide path specific parameters such as scopes_supported and the critical resource identifier.
But I wonder, and it's likely this was discussed as an option in the past, if instead, or in addition to (possibly even exclusive one or the other), there could be resource parameter in the www-authenticate header and the client would
- do the well-known url transformation on it
- fetch the discovery document
- compare the discovered resource matches the one from the www-authenticate
This would allow hosting a single document cached on a CDN in its's proper root location in the more rigid deployments.
(Edit: this is in fact what the draft did at the beginning and the WG decided to go another route, nevertheless, i'm leaving this here for the internet archives).
However, the more important part - this also interacts very badly with query strings in the current state
How does this interact with GET endpoints and their query string parameters? It is a cause for interop concerns. I believe section 3.3 should speak more about this and be explicit, if the client went the route of www-authenticate > resource_metadata and it had query string parameters in the URL we should probably be descriptive about stripping the query string or keeping it. And that will inform the applicability of the SHOULD NOT in the resource identifier definition.
it also SHOULD NOT include a query component, but it is recognized that there are cases that make a query component a useful and necessary part of a resource identifier.
More specifically, if this is to be validated right the www-authenticate has to echo the querystring used for the request into the resource_metadata parameter so that that discovery response can return the exact same URL (incl. querystring).
As a client implementer I know that if I do a strict equality comparison it's bound to fail in some scenarios where the resource URL includes a query component.
As a server implementer I am now constrained to NOT support query strings in my APIs knowing that clients will struggle validating.
Also, a client can include any number of query string parameters for any reason, e.g. for cache busting, and the presence of these is not a reason for the RS to not respond to that request but it is super awkward if the server now has to include these in the www-authenticate parameter just so that a strict validation can be performed.