The API refused. Not because the user lacked permission, but because the scope requested did not match the domain of the resource. That is the point of domain-based resource separation in OAuth scope management: hard boundaries between data realms, enforced at the token level.
OAuth scopes define what a client can access. Most implementations stop there. Domain-based resource separation adds where the client can access by tying scopes directly to the logical domain of the data. A single access token becomes valid only for resources in its assigned domain. Anything outside that boundary triggers an immediate deny.
This approach prevents cross-domain data leakage. It reduces blast radius in case of a compromised token. It allows fine-grained security without complex conditional logic spread across APIs. Each domain — whether by tenant, project, team, or region — has its own scope namespace. The authorization server issues tokens with scopes that are both action-specific and domain-specific, such as read:project123 or write:tenant456.
To implement domain-based separation, start at the authorization server. Define a scope schema that includes both action and domain identifiers. Ensure token issuance checks the client's right to that domain before granting scopes. The resource server then validates scopes on every request, matching both action and domain before processing. This requires consistent domain identifiers across all services involved.