Who’s Who in OAuth 2.0? Understanding the Client and the Authorization Server

A stone wall with a water wheel on it — Photo by Ben Kupke on Unsplash

If you’ve ever signed up for a new app using “Log in with Google” or “Connect with Spotify,” you’ve used OAuth 2.0. This protocol is the backbone of modern delegated access, but its terminology can sometimes feel like alphabet soup.

To truly understand how OAuth works, you just need to focus on two main actors and their responsibilities: the Client (the app that wants access) and the Authorization Server (the trusted gatekeeper).

The Client: The Requesting Party

In the context of OAuth 2.0, the Client is simply the application, website, or service that needs to access a user’s data or functionality on another platform.

Think of the Client as a hotel guest who needs access to a specific room (the user’s protected data). The guest doesn’t own the room, but they need temporary, defined access.

Key Roles of the Client:

Initiates the Flow: The Client starts the entire process by sending the user to the Authorization Server. It identifies itself using a unique Client ID and specifies exactly what data it needs access to (the Scope).
Receives the Authorization Code: After the user approves the request, the Client receives a short-lived Authorization Code from the Authorization Server.
Trades for the Access Token: The Client securely exchanges this code for an Access Token. This exchange often involves a secret key (Client Secret) to prove the Client’s authenticity.
Makes API Calls: The Access Token is then attached to every subsequent request the Client makes to the Resource Server (the API that holds the actual data, like Google Drive or Facebook photos).

In short: The Client is the application responsible for starting the conversation, proving its identity to the server, and using the resulting token to get the job done.

The Authorization Server: The Trusted Gatekeeper

The Authorization Server (AS) is the heart of the OAuth system. Its entire existence is dedicated to verifying users and issuing secure, temporary credentials. It’s usually part of the identity provider (like Google, Microsoft, or your organization’s internal identity management system).

If the Client is the hotel guest, the Authorization Server is the front desk manager. It holds the master keys, knows the security policy, and decides which temporary keys to issue.

Key Roles of the Authorization Server:

Authenticates the User: The AS is responsible for prompting the user to log in (e.g., entering their username and password). Crucially, the Client never sees the user’s credentials.
Manages Consent: It asks the user for explicit Consent. This is the screen where you click “Allow” or “Deny” access to specific scopes (e.g., “Allow this app to see your email address”).
Issues Tokens: Upon successful authentication and user consent, the AS generates and issues the Access Token. This token is a digitally signed ticket that represents the user’s granted permissions.
Token Validation: When the Resource Server receives a request with an Access Token, it often communicates back with the AS to ensure the token is valid, hasn’t expired, and has the correct permissions (scopes).

In short: The Authorization Server is the highly trusted entity that handles all sensitive identity and permission-granting logic, protecting the user’s password from the third-party application.

The Power of Separation

The brilliance of OAuth 2.0 lies in this separation of duties:

Authentication (Who you are) is handled exclusively by the Authorization Server.
Authorization (What you can do) is defined by the Authorization Server and consumed by the Client.

This design ensures that your sensitive credentials never leave the hands of the primary identity provider, giving the Client only a limited, revocable key—the Access Token—to perform its specific tasks.

If you found an error, highlight it and press Shift + Enter or click here to inform us.