One of the design decisions that went into OAuth 2.0 was to explicitly separate the roles of the authorization server from the API server. This means you can build out the authorization server as a standalone component which is only responsible for obtaining authorization from users and issuing tokens to clients. The two roles can be on physically separate servers, and even be on different domain names, allowing each part of the system to be scaled independently. Some providers have many resource servers and each is on a different subdomain.

The authorization server needs to know about the app’s client_id and client_secret, but the API server will only ever need to accept access tokens. By building the authorization server as a standalone component, you can avoid sharing a database with the API servers, making it easier to scale API servers independently of the authorization server since they don’t need to share a common data store.

For example, Google’s OAuth 2.0 implementation uses a server at “accounts.google.com” for authorization requests, but uses “www.gooogleapis.com” when making requests to the Google+ API.

The benefit to service providers is that the development of these systems can happen completely independently, by different teams and on different timelines. Since they are completely separate, they can be scaled independently, or upgraded or replaced without concerning the other parts of the systems.