In OAuth 2.0, must the authorization server and the resource server be separate deployments?

## Roles are responsibilities, not boxes The four names in RFC 6749 §1.1 describe who is responsible for what in an exchange. They do not describe an architecture. Nothing in the framework says the authorization server and the resource server must be different processes, different hosts, different teams or different organisations. The specification separates the roles so that every message can be described precisely; how many pieces of software you deploy is your decision. This trips people in both directions, and the two mistakes are mirror images. ## One deployment, two roles A small veterinary practice may run a single service that signs its clients in, issues access tokens, and also serves the appointment records. That is perfectly conformant. What has to remain true inside it: - something authenticates the **resource owner** and obtains their authorization — that is the authorization server role; - something issues the `access_token` — still the authorization server role; - something establishes that a presented access token is valid and authorises this particular request before any record is returned — that is the resource server role, and it does not evaporate because the issuer is in the same process. The check may be a local lookup rather than a call across a network, but the responsibility is the same one. The usual error here is to conclude that co-deployment makes the validation step optional, or that the resource server "already knows" because the issuer is next door. It does not know; it checks. ## One authorization server, many resource servers The other direction is just as common in practice. The practice's authorization server can issue access tokens that an appointment API accepts and access tokens that a billing API accepts. Each API is a **resource server** in its own right. | shape | authorization servers | resource servers | who validates | |---|---|---|---| | one combined service | 1 (same deployment) | 1 (same deployment) | the resource server role, inside that service | | split pair | 1 | 1 | the resource server, on each request | | one issuer, several APIs | 1 | 2 or more | each resource server, independently | The mistake in this row of the table is to assume that sharing an issuer merges the APIs into one resource server, or that a second API needs an authorization server of its own before it can accept tokens. ## What stays true in every shape 1. The **resource owner** authenticates at the authorization server and nowhere else. 2. Only the **authorization server** role issues access tokens. 3. Every **resource server** validates what is presented to it, for itself, on each request. 4. The **client** presents and never validates; being co-deployed with anything changes none of that. ## Why an interviewer asks it The question is a quick test of whether the candidate learned the role model or learned one deployment diagram from a tutorial. Someone who has only ever seen a split pair will say the separation is mandatory; someone who has only ever run a combined service will say the resource server role does not really exist. Both answers reveal the same gap — the roles have been read as boxes. The better answer names the invariant first and the freedom second: the responsibilities are fixed by the framework, the packaging is yours. Then give both shapes in one breath, a combined service and one issuer serving several APIs, so that it is clear you are describing a model rather than reciting a picture. ## Saying it well in an interview Start with "no — those are roles, not deployments", then immediately show that you know what the roles still oblige: the owner authenticates at the authorization server, the authorization server issues, and every resource server validates on every request whatever the deployment looks like. If you want to make it concrete, describe the small practice that runs one service today and the second API that joins next year and accepts the same issuer's access tokens without any new authorization server appearing.