Why Delegated Authorization? — The Problem OAuth Solves

The Story So Far

Alice uses PhotoProvider, a service where she stores her personal photos.

One day, she discovers PhotoApp, a third-party application that offers beautiful filters and collages.

PhotoApp needs access to Alice’s photos on PhotoProvider.

How should PhotoApp get that access?

You can watch the OAuth 1.0a flow for this same PhotoApp and PhotoProvider example.

---

The Problem — Password Sharing

The most obvious approach is the simplest one.

Alice gives PhotoApp her PhotoProvider username and password.

Without OAuth

PhotoApp now logs into PhotoProvider as Alice and fetches her photos.

This works. But it is deeply dangerous.

What Goes Wrong

1. Full access. Alice only wanted PhotoApp to read her photos. But PhotoApp now has her password — it can do anything Alice can do. Delete photos. Change her email. Reset her account.

2. No revocation. If Alice wants to stop PhotoApp from accessing her photos, she has to change her password. But changing her password also breaks every other application she gave the password to.

3. Password reuse. Many users reuse passwords. If PhotoApp is compromised, Alice’s password leaks — and every other service where she used the same password is now at risk.

4. Breach amplification. PhotoApp now stores hundreds of thousands of user passwords. A single breach at PhotoApp exposes passwords for PhotoProvider, email services, banks, and everything else users connected.

5. No granularity. There is no way to say “read-only access to photos.” The password grants everything.

6. No audit trail. PhotoProvider cannot distinguish between Alice logging in and PhotoApp logging in. Both look identical.

Password Sharing Risks
Full access — no scope control
No selective revocation
Password reuse across services
Breach amplification
No granularity
No audit trail

With OAuth

Now consider the OAuth approach.

Alice never gives PhotoApp her password.

Instead:

1. Alice logs into PhotoProvider directly.
2. PhotoProvider asks Alice: “PhotoApp wants to read your photos. Allow?”
3. Alice approves.
4. PhotoProvider gives PhotoApp credentials representing the authorization Alice granted.

PhotoApp never sees Alice’s password. It only receives authorization to do specific things.

Approach	Access Type	Credential Held by App
Without OAuth	Unlimited access	Alice’s password
With OAuth	Limited, revocable access	Authorization credentials

---

Why Delegated Authorization Is Necessary

The core idea behind OAuth is delegated authorization.

Alice (the resource owner) delegates a limited set of permissions to PhotoApp (the third party) — without sharing her credentials.

This is necessary because:

Problem	OAuth Solution
Apps need user’s password	Apps receive tokens instead
Full access, no limits	Scoped, limited permissions
No revocation without pw change	Tokens can be individually revoked
Password stored by third party	Password never leaves the provider
No distinction between user/app	Provider knows which app is acting

Delegated authorization means:

The user authorizes a specific application to perform specific actions on the user’s behalf, and the application receives credentials that represent only that authorization — not the user’s identity or password.

---

Authentication vs Authorization

These two terms are often confused. The most important mental model to hold is this:

• Authentication: Who is Alice?
• Authorization: What is PhotoApp allowed to do on Alice’s behalf?
• OAuth: How does PhotoApp obtain that delegated authorization without receiving Alice’s password?

OAuth is primarily about authorization, not authentication.

Authentication

Authentication answers the question:

“Who are you?”

It verifies identity.

When Alice types her username and password into PhotoProvider, that is authentication. PhotoProvider verifies that Alice is who she claims to be.

Authorization

Authorization answers the question:

“What are you allowed to do?”

It verifies permissions.

When Alice approves PhotoApp to read her photos, that is authorization. PhotoApp is being authorized to perform a specific action.

The Distinction

Concept	Authentication	Authorization
Question	”Who are you?"	"What can you do?”
Purpose	Verifies identity	Grants/checks permissions
Credentials	Username + password	Access token + scope
Location	Happens at PhotoProvider	Happens at PhotoProvider
Result	User is identified	App is authorized

Why This Matters

OAuth defines how PhotoApp gets authorization to access Alice’s photos. It does not define how Alice proves her identity to PhotoProvider — that is authentication, and it happens separately.

Later, OpenID Connect (OIDC) was built on top of OAuth 2.0 to add a standardized identity/authentication layer. But OAuth itself is an authorization protocol.

• OAuth: “PhotoApp is allowed to read Alice’s photos”
• OIDC (built on OAuth 2.0): “The logged-in user is Alice”

These are different questions.

---

The Three Actors

OAuth 1.0 defines three actors. Understanding what each one knows and does is essential.

Resource Owner — Alice

Alice is the user who owns the protected resources.

Category	Details
What Alice knows	Her PhotoProvider username and password Which applications she has authorized What permissions she granted
What Alice does	Logs into PhotoProvider directly Reviews the authorization request Approves or denies access for PhotoApp
What Alice never does	Give her password to PhotoApp

Alice interacts with PhotoProvider through her browser. She never communicates her password to PhotoApp.

Consumer — PhotoApp

PhotoApp is the third-party application that wants access to Alice’s protected resources.

Category	Details
What PhotoApp knows	Its own application credentials (Consumer Key + Consumer Secret) The Request Token and Access Token it receives during the OAuth flow The associated token secrets
What PhotoApp does	Requests temporary credentials from PhotoProvider Redirects Alice’s browser to PhotoProvider for authorization Exchanges authorized credentials for access credentials Signs every API request using its secrets
What PhotoApp never receives	Alice’s PhotoProvider password

Service Provider — PhotoProvider

PhotoProvider is the service that stores and protects Alice’s resources.

Category	Details
What PhotoProvider knows	Alice’s identity and credentials PhotoApp’s registered application credentials All issued tokens and their associated secrets Which users have authorized which applications
What PhotoProvider does	Authenticates Alice Presents the authorization consent screen Issues temporary and access credentials Validates every signed request from PhotoApp Serves protected resources when requests are properly authenticated

---

Who Communicates with Whom?

This is a critical detail that many beginners get wrong.

The Common Misconception

• WRONG mental model: PhotoApp ──► PhotoProvider ──► PhotoApp (login happens through PhotoApp)

People often think PhotoApp acts as a middleman for the login. It does not.

The Actual Communication Pattern

There are two separate communication channels:

Channel 1 — Server-to-Server: PhotoApp ↔ PhotoProvider

PhotoApp’s server communicates directly with PhotoProvider’s server. This happens for:

• Requesting temporary credentials (Request Token)
• Exchanging the Request Token for an Access Token
• Making signed API requests for protected resources

Channel 2 — Browser: Alice ↔ PhotoProvider

Alice’s browser communicates with PhotoProvider for the authorization step. This is where Alice:

• Logs in to PhotoProvider
• Reviews the consent screen
• Approves or denies the request

The Browser’s Role

The browser is the bridge between the two channels.

• Step 1: PhotoApp redirects Alice’s browser to PhotoProvider
• Step 2: Alice interacts with PhotoProvider directly in her browser
• Step 3: PhotoProvider redirects Alice’s browser back to PhotoApp

Alice’s browser carries the redirect, but PhotoApp never sees what happens inside the browser during Step 2.

The key insight:

PhotoApp tells the browser where to go. Alice tells PhotoProvider what to authorize. The browser carries the result back to PhotoApp. At no point does PhotoApp see Alice’s password or interact with the login page.

---

What Comes Next

Now you understand:

• Why OAuth exists — to eliminate the dangers of password sharing.
• What delegated authorization means — limited, revocable permissions without sharing credentials.
• Who the three actors are and what each one knows.
• How the communication actually flows — server-to-server for API calls, browser for user authorization.

In the next part, we will examine the credential model — the seven distinct credentials that OAuth 1.0 uses, what each one represents, and why every single one is necessary.

---

Key Takeaways

1. OAuth solves the password-sharing problem.
2. Delegated authorization = limited permissions without sharing credentials.
3. Authentication = “Who are you?” | Authorization = “What can you do?”
4. OAuth is primarily about authorization.
5. Three actors:
   • Resource Owner (Alice) — owns the resources
   • Consumer (PhotoApp) — wants access
   • Service Provider (PhotoProvider) — protects resources
6. Two communication channels:
   • Server-to-server — PhotoApp ↔ PhotoProvider
   • Browser — Alice ↔ PhotoProvider
7. The Consumer NEVER receives the user’s password.