In some OAuth 2.0 deployments, the resource server and Authorization Server are operated by the same organization and deployed in the same domain, but many Resource Servers share a single Authorization Server (a security token service (STS) component). Thus, even though the trust between these two is typically tightly bound, there is value in defining a singular standardized resource protection communications interface between the Authorization Server and each of the Resource Servers.
In some deployments of OpenID Connect, which has a dependency on OAuth 2.0, the OpenID Provider (OP) component is a specialized version of an OAuth Authorization Server that brokers availability of user attributes by dealing with an ecosystem of attribute providers (APs). These Attribute Providers effectively function as third-party Resource Servers. Thus, there is value in defining a mechanism by which all of the third-party Attribute Providers can communicate with a central OpenID Provider (OP), as well as ensuring that trust between the Authorization Server and Resource Servers is able to be established in a dynamic, loosely coupled fashion.
In some deployments of User Managed Access UMA, which has a dependency on OAuth 2.0, an end-user Resource Owner (the "user" in UMA) may choose their own Authorization Server as an independent cloud-based service, along with using any number of Resource Servers that make up their "Personal Cloud". Thus, there is value in defining a mechanism by which all of the third-party Resource Servers can outsource resource protection (and potentially discovery) to a central Authorization Server, as well as ensuring that trust between the Authorization Server and Authorization Server is able to be established by the Resource Owner in a dynamic, loosely coupled fashion.