skip to content

What can an authorization server not tell about a client from a claimed https redirect URI it registered?

level: seniorimportance: nice to knowfreq 26%

answer

  1. the wire looks exactly like a web client
  2. an https URL is an https URL
  3. the diversion happens on the device
  4. registration records the client type
  5. no claimant means the site answers

basics

~20 s

It cannot tell that the client is a native application. A claimed https redirect URI is an ordinary HTTPS URL on the wire, identical to what a web client registers, and the diversion to an installed application happens on the device where the server cannot see it.

solid answer

~50 s

In the claimed-`https` form the client registers a normal HTTPS URL, and the operating system holds a verified association between that domain and the installed application. The **authorization server** plays no part in that: it issues the same `302` to the same URL it would for a web client, and whether the platform diverts the navigation into an application or the browser simply loads the page is invisible to it. So the URI carries no information about the client type. That is why RFC 8252 section 8.4 requires the client type to be recorded at registration — the server's knowledge that it is dealing with a native client comes from the client record, never from inspecting the redirect URI. It also follows that if no installed application has claimed the domain, the response lands at the web address itself, so whatever is served there is what the user gets.

code

http · 2 lines
http
HTTP/1.1 302 Found
Location: https://parking.example.gov/oauth2redirect?code=SplxlOBeZQQYbYS6WxSbIA&state=af0ifjsldkj

go deeper

for a junior

Recall that a claimed https redirect URI is a real web address, and that the device is what decides whether an application or the browser handles it.

for a middle

Explain that the authorization response is byte-identical to a web client's, so the client type has to come from the registration record instead of from the URI.

for a senior

Show the operational consequence both ways: the client record is what the server relies on, and the page actually served at that address is part of the design because an unclaimed domain simply loads it.

for a principal

The angle is the trade-off between the form with the strongest on-device binding and the form that tells your authorization server the most, and how you keep the client register honest when the URI cannot corroborate it.

## The form, from the server's side A claimed `https` redirect looks like this in the authorization response, and that is the whole point: ``` HTTP/1.1 302 Found Location: https://parking.example.gov/oauth2redirect?code=SplxlOBeZQQYbYS6WxSbIA&state=af0ifjsldkj ``` There is nothing in it that says "native". A web client's redirection endpoint would produce a byte-identical response. Everything that makes this form special happens afterwards and elsewhere: the **operating system** recognises the domain as one an installed application has been verified against, and diverts the navigation to that application instead of fetching the page. The **authorization server** never observes that step. It issued a redirect; what the device did with it is out of view. ## Why that matters at registration An authorization server's behaviour depends on knowing what kind of client it is talking to. If the redirect URI cannot tell it, something else must, and RFC 8252 section 8.4 is explicit about where: the **client type is recorded at registration**. The client record, not the URI, is the authoritative statement that this is a native application. This is a genuinely counter-intuitive consequence and it is what the question is testing: - The private-use scheme form is **self-announcing** — a `redirect_uri` of `com.example.parking:/oauth2redirect/city` could not belong to a web client. - The loopback form is **self-announcing** — nobody registers `http://127.0.0.1:{port}/` for a web application. - The claimed `https` form is **silent**. It is the one native form that is indistinguishable at the server, and therefore the one that makes recording the client type necessary rather than merely tidy. ## What happens when nothing claims the domain Because the URI is a real address, the failure mode is not an error — it is a page load. 1. The browser follows the redirect to `https://parking.example.gov/oauth2redirect?...`. 2. No installed application has claimed that domain on this device, so nothing diverts it. 3. The request reaches the web server that actually hosts the domain, query string and all. That is a strictly better user experience than a dead end, and it is one of the form's attractions: a user without the application installed sees something rather than a broken link. It is also a design obligation. Whatever is served at that path is now part of the flow, and it should behave sensibly — a plain "open this in the application" page, and nothing that treats the arriving query string as if a session were being established. ## Comparing the three forms on visibility | Form | Visible as native to the authorization server? | Destination verified by the platform? | |---|---|---| | Private-use URI scheme | Yes, from the scheme | No | | Loopback address | Yes, from the host | No | | Claimed `https` URI | No | Yes | The two columns run in opposite directions, and that is the interesting part: the form whose destination is the hardest for another application to steal is also the form that tells the server the least about who it is serving. ## What a good answer includes - The observation itself: an HTTPS redirect URI carries no client-type signal. - The consequence named in section 8.4: the client type is recorded at registration. - The direction of trust: the platform's domain association protects the *destination on the device*; it gives the authorization server nothing, because the server has no way to see it and no way to check it. - The fallback: an unclaimed domain means the browser simply loads the page, so that page is part of the design. ## The mistake to avoid The seductive wrong answer is that a claimed `https` redirect proves something to the server — that the developer controls the domain, or that the recipient is a verified application. The verification is real but it is performed by the device, for the device. Nothing about it travels back to the authorization server in the authorization response, and an answer that lets the server lean on it has inverted who checked what.

  • Why does the authorization server need to know the client type at all?
    Because much of its policy depends on it — what it may expect the client to be able to protect, and how it treats the request. RFC 8252 section 8.4 puts that fact in the client record precisely because the claimed-https redirect URI will not supply it.
  • What should be served at the claimed https address itself?
    Something deliberate and inert: a short page explaining that the response was meant for an installed application, with no attempt to act on the query string it received. The address is reachable by anyone, so it should not be a second, weaker entry point into the flow.
  • Does the platform's domain verification protect the authorization server in any way?
    No. It protects the destination on the device by making the association hard to assert falsely, but it is performed by the operating system for the operating system. The authorization server sees only that it redirected to an HTTPS URL, and has nothing to verify.

saying these in an interview costs you the question

  • Says the authorization server can see which application received the response.
  • Thinks an https redirect URI proves the client is a web application.
  • Assumes an unclaimed https redirect simply fails on the device.
  • Believes the platform's domain verification is visible to the authorization server.
  • Says a native client must never register an https redirect URI.