In OAuth 2.0, which of the four parties hosts the redirection endpoint named by redirect_uri?
answer
- Two hosts, not one
- Which party runs the callback route?
- Named in the request, hosted elsewhere
- Authorization and token endpoints are the server's
- redirect_uri points at the client's own host
basics
~20 sThe client hosts it. The authorization endpoint and the token endpoint are the authorization server's, but the redirection endpoint named by redirect_uri is a route on the client, which the authorization server merely sends the user-agent back to.
solid answer
~40 sThe **client** hosts it. Three named endpoints appear in an authorization exchange and they do not all sit on one party: the **authorization endpoint** and the **token endpoint** are on the **authorization server**, while the **redirection endpoint** — the URL carried in the `redirect_uri` parameter — is a route the client runs. A fourth address, the protected resource itself, belongs to the **resource server**. People misplace the third one because the parameter is *sent to* the authorization server and the client registers that URI there in advance, so registration gets mistaken for hosting. If you put the redirection endpoint on the authorization server you have quietly merged the client into it, and the four-party model collapses. Say which endpoint you mean, too: "the endpoint" with no qualifier is unanswerable on this subject.
code
http · 2 linesGET /authorize?response_type=code&client_id=s6BhdRkqt3&scope=appointments&redirect_uri=https%3A%2F%2Fbooking.example%2Fcb&state=af0ifjsldkj HTTP/1.1
Host: auth.vet-practice.examplego deeper
Remember the ownership: redirect_uri names a route on the client. The authorization server sends the user-agent there; it does not run it. That single fact prevents the most common role mix-up in the whole framework.
Place all the addresses: authorization endpoint and token endpoint on the authorization server, redirection endpoint on the client, protected resource on the resource server. Explain why declaring a URI to a counterparty is not the same as that counterparty hosting it.
Show the downstream cost of getting this wrong: an exchange described as happening entirely on one server hides the party boundary that everything else in the framework is defined across. Be precise about which endpoint you mean every time you say the word.
The angle is boundary ownership across teams: whichever team runs the client owns and must operate that callback route, including its availability, while the authorization server team owns which addresses it will send people to. Those are two different on-call rotations.
## Three named endpoints, two parties An OAuth 2.0 authorization exchange visibly touches three endpoints that the specification names, and they are not all on the same host. - The **authorization endpoint** is on the **authorization server**. It is a destination the resource owner's user-agent is sent to, so that the authorization server can authenticate the owner and obtain their authorization. - The **token endpoint** is on the **authorization server**. The client calls it directly rather than through the user-agent. - The **redirection endpoint** is on the **client**. It is the URL named by the `redirect_uri` parameter, and it is where the authorization server sends the user-agent back once the authorization step is finished. A fourth address takes part but is not one of those three: the protected resource, which lives on the **resource server** and is where the client presents the access token it obtained. So one exchange involves at least two hosts belonging to two different parties, and possibly three. ## Why the third endpoint gets put on the wrong party Four things push people to place the redirection endpoint on the authorization server, and all four are surface features rather than facts about the model. 1. **The parameter is sent *to* the authorization server.** `redirect_uri` appears in a request the client makes to the authorization server, so it reads like something the server owns rather than something the client is declaring about itself. 2. **The visible part of the step happens on the server's pages.** The resource owner sees the authorization server's interface, so the return leg feels like part of that same site. 3. **The client registers the URI with the authorization server in advance.** Registration gets confused with hosting. Registering an address with a counterparty does not make the counterparty the address's owner. 4. **The word "endpoint" is used for all of them.** Authorization endpoint, token endpoint, redirection endpoint, the device authorization endpoint, the resource server's own API — a bare "the endpoint" names none of them. ## What the client actually has to do Being the host of the redirection endpoint is a concrete obligation, not a label. The client has to run a route at that address and be reachable there by the resource owner's user-agent at the moment the authorization step completes. That is what makes the address a property of the client: if the client does not exist at it, the exchange has nowhere to land. ```http GET /authorize?response_type=code&client_id=s6BhdRkqt3&scope=appointments&redirect_uri=https%3A%2F%2Fbooking.example%2Fcb&state=af0ifjsldkj HTTP/1.1 Host: auth.vet-practice.example ``` Two hosts are visible in those two lines. `auth.vet-practice.example` is the authorization server; `booking.example` is the client. They are different parties, and the request is the client telling the server where, on the client, to send the resource owner back to. ## Why the misplacement matters beyond trivia If you believe the redirection endpoint lives on the authorization server, several downstream answers go wrong in the same direction: - you lose the distinction between the party that authenticates the resource owner and the party the owner was trying to use; - you cannot explain why the address has to be declared in advance at all, since a server would hardly need to register a URL with itself; - you end up describing the whole exchange as happening "on the identity provider", which is exactly the two-party picture the four-role model replaces. The role fact is the load-bearing one: **the authorization server never hosts the client's callback**. What it does is send the user-agent to an address the client declared. ## Saying it well in an interview Answer with the ownership first and the reason second: "the redirection endpoint is on the client — `redirect_uri` is the client telling the authorization server where on the client to return the user-agent." Then place the other two endpoints on the authorization server so the interviewer can see you are not guessing, and name the resource server's API as a separate address belonging to a separate party. If you want to show care, add the qualifier habit out loud: on this subject you always say *which* endpoint, because there are at least five of them across the framework and "the endpoint" identifies none.
- If the client hosts the redirection endpoint, why does it have to declare the URI to the authorization server at all?Because the authorization server has to know, in advance, which addresses genuinely belong to that client before it will send a resource owner's user-agent to one. Declaring it is the client describing itself to a counterparty; hosting it remains entirely the client's job.
- Which party hosts the endpoint the access token is finally presented to?The resource server. That is a fourth address, distinct from the authorization server's authorization and token endpoints and from the client's redirection endpoint. Keeping it separate in your head is what stops the client and the resource server being merged.
saying these in an interview costs you the question
- Says the authorization server hosts the callback URL
- Calls redirect_uri an address on the resource server
- Assumes registering a URI means the server hosts it
- Treats the browser as the owner of the callback
- Says the endpoint without naming which one