🔐 OAuth 1.0 Explained: How the Auth Server Knows the User

OAuth 1.0 was the first version of the OAuth protocol, and while it's mostly replaced by OAuth 2.0, it's still important to understand — especially if you work with legacy systems or APIs like Twitter's old API versions.

Let’s walk through the flow step by step and highlight how the Authorization Server figures out the user.

📘 Key Players (Same as OAuth 2.0)

Role	Description
Resource Owner	The user who owns the data
Client	The application that wants access to the user's data
Authorization Server	Handles login, permission, and tokens
Resource Server	The API or server that stores the user’s data

🔁 OAuth 1.0 Flow (Step-by-Step)

OAuth 1.0 is two-legged and three-legged, but we’ll cover the three-legged flow, which involves the user (resource owner).

🧭 Step 1: Client Gets a Request Token

The client first sends a signed request to the Authorization Server to obtain a request token.

POST /oauth/request_token
Authorization: OAuth
    oauth_consumer_key="xyz",
    oauth_signature="...",
    oauth_callback="https://clientapp.com/callback"

✅ This token is not yet tied to a user — it's just the first handshake.

👤 Step 2: Redirect User to Authorization Server

GET /oauth/authorize?oauth_token=requestToken123

The client redirects the user to the Authorization Server with the request token.

🔐 Step 3: User Logs In and Grants Access

The user logs in and approves the request token.

➡️ At this point, the Authorization Server:

Authenticates the user (knows who they are)
Associates the request token with the user

✅ ✅ ✅ So this is when the Authorization Server knows whose data the client wants.

📜 Step 4: Server Sends User Back with a Verifier

After approval, the server redirects back with:

https://clientapp.com/callback?oauth_token=requestToken123&oauth_verifier=abc123

🔄 Step 5: Client Exchanges Request Token + Verifier for Access Token

POST /oauth/access_token
Authorization: OAuth
    oauth_consumer_key="xyz",
    oauth_token="requestToken123",
    oauth_verifier="abc123",
    oauth_signature="..."

The access token returned is now tied to:

The client
The user (because of login and approval)
The granted scopes (permissions)

🔓 Step 6: Client Accesses User’s Data

GET /api/profile
Authorization: OAuth oauth_token="accessToken456", oauth_signature="..."

The client uses the access token to request user data from the Resource Server.

✅ The token is linked to the user, so the Resource Server serves that user’s data.

🔐 How Does Auth Server Know the User?

In OAuth 1.0:

During Step 3, the user logs in and approves the request token.
The Authorization Server associates that token with the user.
The later access token is generated based on that association.

So again, the flow answers the question clearly:

✅ The Authorization Server knows the user because they log in and grant access to the request token.

🔍 OAuth 1.0 vs OAuth 2.0 (TL;DR)

Feature	OAuth 1.0	OAuth 2.0
Token Type	Request + Access tokens	Access + optional Refresh tokens
Signature Requirement	HMAC-SHA1 signatures	Optional (Bearer tokens)
Complexity	More complex	Simpler, more flexible
User Login & Consent	Required to link request token	Required to issue access token
Security	Stronger with signatures	Token can be bearer, needs HTTPS

✅ Conclusion

OAuth 1.0 may be older, but its flow was very secure due to request signing.

It knew whose data was being accessed because:

The user logged in
The user granted permission
The server linked the request token to the user

This is similar in principle to OAuth 2.0 — but with more cryptographic signatures and complexity.