Every OAuth flow involves four distinct roles, and most confusion about "who talks to whom" traces back to conflating two of them:
| Role | Who this is, in a "Login with Google" example |
|---|---|
| Resource Owner | The end user — the person who owns the Google account and can grant or deny access to it |
| Client | Your application — the thing requesting access on the user's behalf |
| Authorization Server | Google's login/consent infrastructure — issues tokens after the user approves |
| Resource Server | Google's actual API (Calendar API, People API) — accepts the access token and returns data |
The Authorization Server and Resource Server are frequently the same company (Google issues the token and runs the API that accepts it) but they're logically separate roles, and in some systems they really are separate services — a company might run its own internal Authorization Server (e.g. an identity provider like Okta or Auth0) that issues tokens accepted by several unrelated internal APIs, each of which is its own Resource Server.