OAuth 1.0 Credentials and Token Model

Why Start with Credentials?

Before walking through the OAuth 1.0 protocol step by step, you need to understand the building blocks — the credentials that flow between actors at each stage.

OAuth 1.0 uses seven distinct credential values. If you don’t know what each one is, who creates it, and what it proves, the protocol flow will feel like arbitrary steps.

This part explains every credential in depth. You can watch those credentials move in the OAuth 1.0a simulation.

The Seven Credentials — Overview

Application Credentials

Consumer Key
Consumer Secret

Temporary Authorization Credentials

Request Token
Request Token Secret
OAuth Verifier

Long-Lived Access Credentials

Access Token
Access Token Secret

Each credential serves a specific purpose in the protocol. None is redundant.

Credential Deep Dive

1. Consumer Key

Property	Detail
Who creates it	PhotoProvider (Service Provider)
Who receives it	PhotoApp (Consumer)
Where it is stored	PhotoApp’s configuration; also in PhotoProvider’s registry
What it identifies	The registered application (PhotoApp)
What it proves	Nothing by itself — it is a public identifier
When it is used	Every OAuth request from PhotoApp to PhotoProvider
When it becomes invalid	When PhotoProvider revokes or deletes the application registration

The Consumer Key is like a username for the application. It tells PhotoProvider which application is making a request.

consumer_key = photo-app-123

The Consumer Key is not secret. It appears in OAuth requests and can be visible in URLs or headers.

2. Consumer Secret

Property	Detail
Who creates it	PhotoProvider (Service Provider)
Who receives it	PhotoApp (Consumer)
Where it is stored	PhotoApp’s server-side configuration; also in PhotoProvider’s registry
What it identifies	Nothing — it authenticates the application identified by the Consumer Key
What it proves	That the request originates from the legitimate PhotoApp, not an impersonator
When it is used	Every request — as part of the signature computation (never sent directly)
When it becomes invalid	When PhotoProvider rotates or revokes it

The Consumer Secret is like a password for the application. It proves that the entity claiming to be photo-app-123 actually is PhotoApp.

consumer_secret = SECRET_APP

The Consumer Secret must be kept confidential. It should never be exposed in browser JavaScript, mobile app binaries (where it can be reverse-engineered), or logs.

The Consumer Secret is used to compute signatures, not sent directly in requests. PhotoProvider has its own copy and independently verifies the signature.

3. Request Token

Property	Detail
Who creates it	PhotoProvider (Service Provider)
Who receives it	PhotoApp (Consumer)
Where it is stored	PhotoApp stores it temporarily; PhotoProvider tracks it in its token store
What it identifies	A specific, in-progress authorization request
What it proves	That PhotoApp initiated an authorization process with PhotoProvider
When it is used	During user authorization (sent in the redirect URL) and during the Access Token exchange
When it becomes invalid	After it is exchanged for an Access Token, or after a timeout

The Request Token is a temporary, single-use credential that exists only during the authorization process.

request_token = REQUEST_ABC

It does not grant access to Alice’s photos. It only identifies an authorization request that is in progress.

4. Request Token Secret

Property	Detail
Who creates it	PhotoProvider (Service Provider)
Who receives it	PhotoApp (Consumer)
Where it is stored	PhotoApp’s temporary session storage; PhotoProvider’s token store
What it identifies	Nothing — it is a component of the signing key used during token exchange
What it proves	Not a standalone proof; it is used in the signature to prove the caller holds the secret
When it is used	When signing the Access Token exchange request
When it becomes invalid	When the Request Token is exchanged or expires

request_token_secret = REQUEST_SECRET

The Request Token Secret is used as part of the signing key when the Consumer signs the access-token request. It isn’t itself a standalone proof mechanism, but rather a required component to cryptographically bind the exchange request.

5. OAuth Verifier

Property	Detail
Who creates it	PhotoProvider (Service Provider)
Who receives it	PhotoApp (Consumer) — via the browser redirect callback
Where it is stored	PhotoApp stores it temporarily; PhotoProvider tracks it with the Request Token
What it identifies	Nothing — it is a proof of user authorization
What it proves	That Alice actually approved the authorization request
When it is used	Once — during the Access Token exchange
When it becomes invalid	After the Access Token exchange, or after a short timeout

oauth_verifier = VERIFIER_XYZ

The verifier is the crucial bridge between the user authorization step and the token exchange step. Without it, PhotoApp could attempt to exchange the Request Token without Alice’s approval.

The OAuth Verifier was introduced in OAuth 1.0a to fix a session fixation vulnerability in the original OAuth 1.0 specification.

6. Access Token

Property	Detail
Who creates it	PhotoProvider (Service Provider)
Who receives it	PhotoApp (Consumer)
Where it is stored	PhotoApp’s persistent storage; PhotoProvider’s token store
What it identifies	Alice’s specific authorization grant to PhotoApp
What it proves	That PhotoApp has been authorized by Alice to access her resources
When it is used	Every protected API request
When it becomes invalid	When Alice revokes authorization, or when PhotoProvider invalidates the token

access_token = ACCESS_123

The Access Token is the final credential that PhotoApp uses for ongoing API access. It represents Alice’s authorization.

7. Access Token Secret

Property	Detail
Who creates it	PhotoProvider (Service Provider)
Who receives it	PhotoApp (Consumer)
Where it is stored	PhotoApp’s persistent secure storage; PhotoProvider’s token store
What it identifies	Nothing — it authenticates possession of the Access Token
What it proves	Cryptographic proof that the entity making the request possesses the token’s secret
When it is used	Every protected API request — as part of the signature computation
When it becomes invalid	When the Access Token is revoked or invalidated

access_token_secret = ACCESS_SECRET

Like the Consumer Secret, the Access Token Secret is never sent directly in requests. It is used locally to compute the request signature.

Why Consumer Key + Consumer Secret Aren’t Enough

This is a question beginners naturally ask:

“PhotoApp already has a Consumer Key and Consumer Secret. Why can’t those be used to access Alice’s photos?”

The answer is fundamental.

Application credentials identify the application, not the user

The Consumer Key and Consumer Secret identify and authenticate PhotoApp — the application.

They say:

"This request is from PhotoApp, and we can prove it."

They do not say:

"Alice has authorized this request."

One application, thousands of users

PhotoApp might have 100,000 users. All of them share the same Consumer Key and Consumer Secret.

Type	Credential	Note
Consumer Key	`photo-app-123`	Same for all users
Consumer Secret	`SECRET_APP`	Same for all users
Alice’s Access Token	`ACCESS_ALICE`	Unique to Alice
Bob’s Access Token	`ACCESS_BOB`	Unique to Bob
Charlie’s Access Token	`ACCESS_CHARLIE`	Unique to Charlie

If Consumer credentials alone were sufficient, then:

PhotoApp could access any user’s photos — there is nothing that says “Alice authorized this.”
There would be no way to revoke a single user’s authorization without affecting all users.
There would be no concept of per-user permissions.

Therefore

Application credentials and user authorization credentials must be separate.

Consumer Key + Secret: “This is PhotoApp, verified”
Access Token + Secret: “Alice authorized PhotoApp to read her photos”

Both are required. Neither is sufficient alone.

The Four Questions Behind Every Protected Request

Which application is calling? → Consumer Key
Can the application prove it knows its secret? → Consumer Secret (through the signature)
Which authorization is being used? → Access Token
Can the request be cryptographically verified for that authorization? → Access Token Secret (through the signature)

This is why OAuth 1 has both application credentials and token credentials. They solve two different identity/authorization problems.

Why Does OAuth 1.0 Need a Request Token?

This is perhaps the most confusing part for beginners.

The Natural Question

“When Alice logs into PhotoProvider and clicks ‘Allow,’ why doesn’t PhotoProvider just hand back the Access Token right there? Why do we need a temporary Request Token first?”

The Answer

The Request Token exists because the authorization process has multiple steps that involve different actors and different communication channels.

Let’s trace the full lifecycle:

While there is a general security concern about exposing long-lived Access Tokens in browser URLs and history, the primary reason for the Request Token is about establishing a secure transaction model.

The Request Token acts as a claim ticket that binds the entire flow together:

Without the Request Token, there is no cryptographic link between “PhotoApp started this request” and “PhotoApp is now exchanging for an Access Token.” The Request Token ensures the final server-to-server exchange is directly tied to the authorization Alice granted in the browser.

Request Token vs Access Token

Property	Request Token	Access Token
Purpose	Identifies an in-progress authorization request	Represents completed user authorization
Lifetime	Temporary — minutes	Long-lived — until revoked
Usage count	Used once, then exchanged	Used for every API request
Grants resource access	No	Yes
Created when	PhotoApp asks to start authorization	After successful token exchange
Invalidated when	After exchange or timeout	When user/provider revokes it
Travels through browser	Yes (in redirect URL)	No (server-to-server exchange)

Credential Lifecycle Diagram

This diagram shows how credentials flow through the entire OAuth 1.0 process:

Each step produces credentials that are consumed by the next step. The standard OAuth 1.0a flow is sequential: each stage produces information required by the next stage.

Who Knows What?

Understanding which actor possesses which credential is essential for reasoning about security.

Value	Consumer (PhotoApp)	Provider (PhotoProvider)	User / Browser (Alice)
Consumer Key	✅	✅	❌
Consumer Secret	✅	✅	❌
Request Token	✅	✅	⚠️ Browser flow
Request Token Secret	✅	✅	❌
OAuth Verifier	✅	✅	⚠️ Browser flow
Access Token	✅	✅	❌
Access Token Secret	✅	✅	❌
User’s Password	❌	✅	✅

✅ = Knows and stores, ❌ = Never receives, ⚠️ = Passes through browser but is not intended for the user

Key Observations

Secrets stay between Consumer and Provider. The Consumer Secret, Request Token Secret, and Access Token Secret never pass through the browser. They are exchanged server-to-server.

The Request Token and Verifier briefly pass through the browser as part of the redirect URLs. This is why they are temporary and single-use — their brief browser exposure is mitigated by their short lifetime and the requirement for additional secrets during the exchange.

Alice’s password is never known by PhotoApp. This is the fundamental guarantee of OAuth.

Both the Consumer and Provider know all OAuth credentials. This is necessary because the Provider must independently verify signatures computed using those secrets.

What Comes Next

You now understand every credential in OAuth 1.0 — what it is, who creates it, what it proves, and why it exists.

In the next part, we will walk through the complete authorization flow step by step, showing exactly when and where each credential appears, with concrete values at every stage.

Key Takeaways

Seven credentials, three categories:
- Application: Consumer Key + Consumer Secret
- Temporary: Request Token + Request Token Secret + Verifier
- Access: Access Token + Access Token Secret
Consumer Key + Secret identify the APPLICATION. Access Token + Secret represent USER AUTHORIZATION. Both are required — neither alone is sufficient.
The Request Token is a temporary claim ticket, NOT permission to access resources.
The Verifier proves the user actually approved the authorization request.
Secrets (Consumer Secret, Token Secrets) are NEVER sent directly — they are used to compute signatures.
The user’s password NEVER reaches the Consumer.

Tags: #OAuth 1.0 #Authorization #System Design #Interview Prep

OAuth 1.0 Credential Model — Every Key, Token & Secret Explained