After a native app's OAuth 2.0 authorization request opens in the device's browser, how does the response reach the app?

## The problem the redirect has to solve A web client's redirection endpoint is a URL on a server it runs, so the authorization response just arrives there. A native client has no such place. Its authorization request was deliberately rendered in a browser it does not control, and the answer comes back as an HTTP redirect **in that browser**. Something on the device has to carry the response across the process boundary and into the application that started the flow. Throughout, the division of labour is fixed: the **authorization server** issues a redirect response to the registered `redirect_uri`; the **browser** follows it; the **operating system** (in two of the three forms) decides which local process the target belongs to. The authorization server never contacts the application. ## Form 1 — a private-use URI scheme The client registers a `redirect_uri` whose scheme is not `http` or `https` but a string the application has declared to the platform: ``` com.example.app:/oauth2redirect/example-provider ``` - The scheme **should be a domain name under the developer's control, written in reverse order**. That is what makes an accidental collision with another installed application unlikely. - There is **one slash**, not two. A `//` introduces an authority component, and a private-use scheme has no naming authority to put there. - Delivery is the platform's: the browser hands the URI over, the operating system looks up who declared the scheme, and that application is launched or resumed with the URI. The weakness is in that lookup. Nothing registers private-use schemes globally, so another installed application may declare the same string and become the recipient. ## Form 2 — a claimed `https` URI The client registers an ordinary-looking HTTPS URL, and the platform holds a **verified association** between that domain and the installed application, so a navigation to it is diverted to the application instead of being fetched. - The destination is the strongest of the three, because the association rests on the operating system checking something published under a domain the developer controls — another application cannot simply declare it. - The cost is that it requires the platform's association mechanism to be in place, and the URL is a real address: if no installed application has claimed it, the browser just loads the page there. - To the authorization server the registration is indistinguishable from a web client's. ## Form 3 — a loopback redirect The application opens a short-lived HTTP listener on the device's own loopback interface and registers `http://127.0.0.1:{port}/{path}` or `http://[::1]:{port}/{path}`. - Nothing is diverted: the browser makes a normal HTTP request to the local listener, which reads `code` and `state` straight off the query string. - Plain `http` is acceptable here because the request never leaves the device. - The port is taken from the operating system at run time, which is why an authorization server has to allow any port on a loopback redirect at request time. - It suits applications on a general-purpose computer far better than a phone, where running a listener is often not an option. ## Choosing between them | Form | Who routes the response | What binds it to the right app | Main exposure | |---|---|---|---| | Private-use URI scheme | operating system, by declared scheme | nothing but the scheme string | another app declaring the same scheme | | Claimed `https` URI | operating system, by verified domain association | the platform's domain check | falls back to loading the web page | | Loopback address | nobody — the browser calls the app directly | the app holding the port | another local process taking the port | A client can register more than one, and typically does when it runs on several kinds of device. What it cannot do is treat the choice as cosmetic: each form fails in a different way, and the failure is local to the device rather than on the network. ## Where the neighbouring half sits All three forms carry the authorization code across a hop the client does not fully control, so all three raise the same question: what if it lands in the wrong process? The answer is a separate mechanism — the per-request proof key of the authorization-code flow (RFC 7636) — which is what makes an intercepted `code` unusable. The redirect form decides *where the code can land*; it is not what makes a captured one worthless.