Before there were four roles, there was one bad habit: sharing passwords. Understanding the problem OAuth solved makes the four roles feel obvious instead of abstract.

In the early days of the web, if you wanted a photo-printing website to grab your vacation photos from another site, there was really only one way to do it: you typed your username and password for the photo site directly into the printing site’s login form. The printing site would then log in as you, pretending to be you, and pull whatever it wanted. This approach is called the “password anti-pattern,” and it has three enormous problems. First, the printing site now permanently knows your real password. Second, it can access everything in your account, not just your photos — your private messages, your billing details, all of it. Third, the only way to cut off access later is to change your password everywhere, which also logs out every other app you’ve connected.

OAuth 2.0 (Open Authorization, version 2.0) was created to solve exactly this problem. Instead of handing out your real password, you hand out a narrow, revocable, time-limited token — like that valet key — that says “this app may read my photos, and nothing else, until this date.” To make that promise possible, the system needs more than just “you” and “the app.” It needs a party that owns the data, a party that wants the data, a party that issues the permission slip, and a party that actually checks the permission slip before handing over the data. Those four separate jobs are the four roles of OAuth 2.0: the Resource Owner, the Client, the Authorization Server, and the Resource Server.

The Resource Owner is almost always you. It’s the human whose data, files, or account is at stake, and the only role in the entire system with the authority to say “yes, you may access this.”

The Resource Owner is defined very simply: it’s whoever owns the protected data and has the right to decide who can touch it. In the vast majority of everyday examples, the Resource Owner is a human being — you, sitting at your laptop or holding your phone, clicking “Allow” on a screen that says “TripPlannerApp wants to view your Google Calendar.” You are the owner of that calendar data. Google is not the owner; Google is just the custodian. TripPlannerApp is not the owner either; it’s the one asking for permission.

It’s worth noting that the Resource Owner does not have to be a human. In some setups — often called “machine-to-machine” flows — a piece of software or a company system can act as its own Resource Owner, granting permission to another piece of software without any person clicking a consent button in the moment. But for the login and permission-screen experiences most people encounter daily (connecting a fitness app to health data, letting a scheduling tool see your calendar, allowing a music app to post to your social account), the Resource Owner is you, personally.

The Client is the application requesting access to your data. Confusingly, in OAuth vocabulary, “Client” does not mean “the customer” — it means “the app doing the asking.”

The Client is any application — a website, a mobile app, a smart TV app, a background service — that wants to access data belonging to the Resource Owner, but that data lives somewhere else, on a different system, guarded by a different company. The Client itself never sees your password. Its entire job is to ask nicely, receive a limited-purpose token if you approve, and then use that token to make requests for the specific data it was granted.

OAuth 2.0 recognizes two flavors of Client, and the difference matters a lot for security:

The Authorization Server is the system that checks your identity, asks for your consent, and then issues the actual token the Client will use. It is the single most trusted component in the whole picture.

The Authorization Server has two jobs, and it’s helpful to picture them as two rooms in the same building. In the first room, it verifies who you are — this is usually a familiar login screen where you enter your username and password, and possibly a second factor like a code from your phone. In the second room, once it knows who you are, it shows you the consent screen: “TripPlannerApp wants to view your calendar — Allow / Deny.” If you click Allow, the Authorization Server generates a token and hands it, indirectly, to the Client.

Well-known Authorization Servers include Google’s accounts system, Microsoft’s Entra ID (formerly Azure AD), Auth0, Okta, and GitHub’s OAuth apps platform. When a company builds a “Sign in with GitHub” button, GitHub’s servers are acting as the Authorization Server for that flow.

The Resource Server is the system that actually stores your protected data and hands it over — but only after checking that the token presented to it is valid and covers the right permissions.

The Resource Server is often a completely different piece of infrastructure from the Authorization Server, even when both are run by the same company. For example, at Google, the servers that handle login and consent screens are logically separate from the servers that actually store your Gmail messages or Calendar events. When TripPlannerApp wants your calendar entries, it doesn’t ask the Authorization Server for the data directly — it presents its access token to the Calendar Resource Server, which checks the token and, if everything is valid, returns just the calendar data the token allows.

Individually, the four roles are simple. The magic of OAuth 2.0 is in the sequence they follow together — a carefully choreographed handoff of trust from the person to the app.

Picture the most common version of this dance, called the Authorization Code flow, which is what powers most “Sign in with…” buttons on websites today. It happens in a clear, repeatable sequence:

sequenceDiagram
    participant RO as Resource Owner (You)
    participant C as Client (TripPlannerApp)
    participant AS as Authorization Server (Google Login)
    participant RS as Resource Server (Google Calendar API)

    RO->>C: Click "Connect Google Calendar"
    C->>AS: Redirect with requested scopes
    AS->>RO: Show login + consent screen
    RO->>AS: Approve access
    AS->>C: Return authorization code
    C->>AS: Exchange code + client secret for token
    AS->>C: Return access token
    C->>RS: Request calendar data with access token
    RS->>C: Return calendar events
        

Notice what never happens anywhere in this sequence: at no point does TripPlannerApp (the Client) ever see your Google password. It only ever sees an access token — a narrow, revocable permission slip — and it only ever uses that token against the specific Resource Server it was issued for.

Understanding the four roles is step one. Step two is understanding where things go wrong when a role’s boundaries get blurred or a step in the handshake gets skipped.