OAuth 1.0 Security and Interview Guide

Before We Begin

In the previous parts, you learned:

Part 1: Why OAuth exists and who the actors are.
Part 2: The seven credentials and what each one proves.
Part 3: The complete authorization flow.
Part 4: Request signing, nonces, timestamps, and replay protection.

This final part ties everything together — the security model, what happens when things go wrong, how OAuth 1.0a improved the original, how OAuth 1.0 compares to OAuth 2.0 architecturally, and a comprehensive interview preparation section.

You can watch the OAuth 1.0a flow that these parts describe, including the verifier and the signed Photo API call.

Secret Compromise — What Happens When Credentials Leak?

Every security system must be evaluated by what happens when parts of it are compromised. OAuth 1.0 has multiple layers of credentials, and each compromise has different consequences.

Compromise Table

Secret Compromised	Consequence
Consumer Secret	Application impersonation risk. An attacker with the Consumer Secret can impersonate the application when generating signed OAuth requests. This compromises the application’s identity and can undermine authorization flows, depending on the provider’s implementation.
Request Token Secret	Temporary authorization-flow risk. An attacker who also has the Request Token could potentially sign the token exchange request — but they still need the Verifier, which requires user authorization. Short-lived, limited blast radius.
Access Token (alone)	User authorization identifier exposed. Without the Access Token Secret, the attacker cannot sign valid requests. Limited direct impact.
Access Token + Access Token Secret	Full compromise for that user. The attacker has the user’s authorization credential pair, but still needs the Consumer Secret to create valid HMAC-SHA1 signatures. If the Consumer Secret is also compromised, the attacker can make authenticated requests for that user’s authorization.
Consumer Secret + Access Token + Access Token Secret	Worst case. The attacker can: 1. Impersonate PhotoApp 2. Sign requests on Alice’s behalf 3. Access Alice’s protected resources

Key Observations

Token Secret alone is generally insufficient. Without the corresponding token identifier, the secret cannot be used. Without the Consumer Secret, a valid signing key cannot be constructed.

The Consumer Secret should remain server-side. It must not be exposed in:

❌ Browser JavaScript (visible in source/devtools)
❌ Mobile app binaries (can be reverse-engineered)
❌ Public repositories (accidental commit)
❌ Client-side logs
❌ Error messages returned to users

The Consumer Secret is shared across all users. Its compromise affects the security of the entire application, not just one user.

Access Tokens can be individually revoked. If Alice’s Access Token is compromised, she can revoke it at PhotoProvider without affecting any other user. This is a major advantage over password sharing.

OAuth 1.0 vs OAuth 1.0a

The original OAuth 1.0 specification had a security vulnerability. OAuth 1.0a (RFC 5849) was released to fix it.

What Was the Problem?

In OAuth 1.0 (without the “a”), the authorization flow had a session fixation vulnerability:

OAuth 1.0 (original):

Attacker obtains a valid Request Token
Attacker tricks Alice into authorizing THAT Request Token (e.g., via a crafted link)
Since OAuth 1.0 had no verifier, the Request Token was sufficient to exchange for an Access Token
Attacker exchanges the Request Token for an Access Token → Attacker now has access to Alice’s resources

The core problem was that the authorization step did not produce a verifier that had to be presented during the Request Token exchange. OAuth 1.0a added that binding between authorization and token exchange.

What Changed in OAuth 1.0a

The key security change in OAuth 1.0a was the introduction of the OAuth Verifier. OAuth 1.0a also strengthened callback handling by requiring the callback to be established during the Request Token flow and providing callback confirmation.

Fix 1: OAuth Verifier (The Key Security Change)

After user authorization, PhotoProvider generates a verifier (VERIFIER_XYZ) and delivers it through the callback.
The Consumer must present this verifier during the token exchange.
This binds the user’s approval to the exchange.

Fix 2: Callback Confirmation & Registration

The callback URL is sent during the initial Request Token request (not just at authorization).
This prevents callback URL substitution attacks.
The provider confirms it with oauth_callback_confirmed=true.

Where the Verifier Appears in the Flow

Why OAuth 1.0a Is the Standard

OAuth 1.0 (original): Known session fixation vulnerability, Deprecated. OAuth 1.0a (RFC 5849): Fixes the vulnerability, Adds the verifier, This is what people mean when they say “OAuth 1.0”.

When the industry refers to “OAuth 1.0,” they almost always mean OAuth 1.0a.

Throughout this series, the flow we described includes the verifier — we have been describing OAuth 1.0a. The two versions are not identical, and the distinction matters for security understanding.

OAuth 1.0 vs OAuth 2.0 — Architectural Philosophy

OAuth 2.0 is not simply “OAuth 1.0 with a version bump.” It is a fundamentally different architectural approach.

Core Philosophical Difference

OAuth 1.0:

Every protected request is cryptographically signed.
Security is built into the protocol at the request level.
Complex but self-contained.

OAuth 2.0:

Typically uses bearer access tokens over TLS.
Bearer-token deployments rely heavily on TLS for transport security rather than requiring OAuth-level per-request signatures.
Simpler protocol, more dependent on infrastructure.

Why OAuth 2.0 Doesn’t Need Per-Request Signing

In OAuth 1.0, the signing mechanism serves two purposes:

Prove the request was not tampered with.
Prove the request was created by someone who has the secrets.

OAuth 2.0’s typical approach says:

“If the connection is over HTTPS, then: TLS already ensures integrity (no tampering), TLS already ensures confidentiality (no eavesdropping), The bearer token proves authorization, We don’t need a per-request signature”

This makes OAuth 2.0 significantly simpler to implement, but it also means:

OAuth 2.0 bearer-token security relies heavily on TLS and on protecting the bearer token itself. Anyone who obtains a valid bearer token can generally use it without proving possession of another signing secret.
OAuth 1.0 request signing provides an additional request-level security mechanism beyond TLS. Even if transport protection is compromised, an attacker who does not possess the signing secrets cannot create a new valid signature.

OAuth 2.0 Sender-Constrained Mechanisms

It is inaccurate to say OAuth 2.0 is “inherently insecure” compared to OAuth 1.0. OAuth 2.0 supports optional sender-constrained mechanisms:

DPoP (Demonstration of Proof-of-Possession): The client proves it holds a private key. Similar philosophy to OAuth 1.0 signing.
mTLS (Mutual TLS): Both client and server present certificates. Client identity is verified at the TLS level.

These mechanisms bring OAuth 2.0 closer to OAuth 1.0’s per-request proof model when stronger security is needed.

Comparison Table

Concept	OAuth 1.0	OAuth 2.0
Request authentication	Cryptographic signatures	Usually bearer access tokens
Per-request signing	Required (core)	Not normally required
Transport security	HTTPS strongly recommended / expected in secure deployments	HTTPS is fundamental to secure bearer-token deployments
Credential / grant model	Request Token + Access Token	Multiple grant/credential patterns, commonly Auth Code + Access Token, optionally Refresh Token
PKCE	Not applicable	Yes, commonly used
OIDC	No	Built on OAuth 2.0
Sender-constrained tokens	Built-in (signing)	Optional (DPoP, mTLS)
Implementation complexity	Complex (signing)	Simpler
Client types	Primarily server-side	Designed for all (browser, mobile, server, IoT)
Ecosystem status	Legacy	Modern standard

The Takeaway

OAuth 2.0 is NOT simply “OAuth 1.0 with a new version number.”

It is a substantially redesigned authorization framework with a different security philosophy, different credential types, different flows, and a much broader scope.

One-Minute Interview Summary

If an interviewer asks — “Explain OAuth 1.0” — a concise answer is:

OAuth 1.0 is an authorization protocol that allows a third-party application to access a user’s protected resources without receiving the user’s password. The application first registers with the service provider and receives a Consumer Key and Consumer Secret. When a user wants to authorize the application, it obtains a temporary Request Token, redirects the user to the service provider for login and consent, receives a Verifier proving the user approved, and exchanges the Request Token plus Verifier for an Access Token. Every protected request is then cryptographically signed using the Consumer Secret and Token Secret — the secrets are never sent directly, only used to compute signatures. Nonces and timestamps help prevent replay attacks. OAuth 1.0a added the Verifier to fix a session fixation vulnerability in the original specification.

Interview Preparation

Beginner Questions

Q: What is OAuth 1.0?

OAuth 1.0 is an authorization protocol that lets a third-party application access protected resources on behalf of a user without obtaining the user’s password. It uses temporary request tokens, access tokens, and cryptographic request signatures.

Q: What are the three actors in OAuth 1.0?

Resource Owner (the user who owns the resources), Consumer (the third-party application wanting access), and Service Provider (the service that protects the resources).

Q: What is the difference between authentication and authorization?

Authentication verifies who you are (identity). Authorization determines what you can do (permissions). OAuth is primarily an authorization protocol.

Q: What is the Request Token?

A temporary credential used during the authorization process. It identifies an in-progress authorization request. It is NOT the final credential for accessing protected resources.

Q: What is the Access Token?

The credential that the Consumer uses for ongoing authorized access to the user’s protected resources. It represents a specific user’s authorization grant to a specific application.

Q: Does the Consumer receive the user’s password?

No. The user authenticates directly with the Service Provider. The Consumer receives authorization credentials (tokens), never the user’s password.

Intermediate Questions

Q: Why does OAuth 1.0 sign requests?

Request signing provides integrity (proves the request wasn’t modified) and authentication (proves the request was created by someone who possesses the Consumer Secret and Token Secret). Without signing, bearer-style tokens could be stolen and used by anyone.

Q: What is the OAuth Verifier?

A value returned after the user authorizes a Request Token. It proves that the user actually approved the request. The Consumer must present it during the Access Token exchange. It was introduced in OAuth 1.0a to prevent session fixation attacks.

Q: Why can’t Consumer Key + Consumer Secret represent a user?

Consumer credentials identify the application, not a specific user. One application serves thousands of users. Application credentials and user authorization must be separate — otherwise there would be no per-user access control or revocation.

Q: Why can’t we directly issue an Access Token after user login?

The Access Token exchange is intentionally separated from the user-agent authorization step. The browser carries the authorization interaction and verifier, while the Consumer performs the final credential exchange directly with the Provider. This prevents the final Access Token credential from being delivered through the browser-based authorization redirect.

Q: Where do the Consumer Secret and Token Secret appear in the request?

They do NOT appear in the request at all. They are used locally to compute the signing key for the HMAC-SHA1 signature. The provider has its own copies and independently recalculates the expected signature.

Security Questions

Q: What happens if the Consumer Secret is leaked?

An attacker with the Consumer Secret can impersonate the application when generating signed OAuth requests. This compromises the application’s identity and can undermine authorization flows, depending on the provider’s implementation.

Q: What happens if an Access Token is leaked (without the Token Secret)?

Limited direct impact. Without the Access Token Secret, the attacker cannot compute valid request signatures. The token alone is an identifier, not a complete credential.

Q: What happens if both Access Token + Access Token Secret are leaked?

The attacker can sign requests on the affected user’s behalf (assuming they also have the Consumer Secret, which forms the other half of the signing key). The user should revoke the token immediately.

Q: Why should the Consumer Secret stay server-side?

The Consumer Secret is shared across all users and is half of every signing key. If exposed in browser JavaScript or mobile app binaries, it can be extracted and used to impersonate the application. It should only exist on the server.

Q: What happens if the Request Token is replayed?

Limited impact. The Request Token doesn’t grant resource access. It requires user authorization (which the attacker can’t force), the Verifier (delivered to the registered callback), and the Consumer Secret + Request Token Secret for signing the exchange. It is temporary and expires quickly.

Signing Questions

Q: Does the OAuth 1.0 signature encrypt the request?

No. Signature provides integrity and authentication. Encryption provides confidentiality. OAuth 1.0 signatures do not hide request content — HTTPS/TLS is needed for that.

Q: What is the signing key?

The signing key is constructed as consumer_secret & token_secret. For Request Token requests, the token secret is empty: consumer_secret &. For protected resource requests: consumer_secret & access_token_secret.

Q: Why does every API request need a new signature?

Because the timestamp and nonce are different for each request, the signature base string changes, producing a different signature. This is by design — identical signatures would make replay detection impossible.

Q: Why can two identical API calls have different signatures?

The timestamp and nonce differ between requests. Since they are part of the signature base string, even requests to the same endpoint with the same parameters produce different signatures.

Q: What causes “Invalid Signature” errors?

Common causes: incorrect parameter sorting, wrong percent-encoding, URL normalization issues, using the wrong secret (e.g., request token secret vs access token secret), missing the trailing & in the signing key, including oauth_signature in the base string, or significant clock skew.

Scenario Questions

Q: What happens if client/server clocks differ significantly?

The timestamp validation will fail. If the difference exceeds the provider’s acceptable window (typically ±5 minutes), the request will be rejected. Clock synchronization (e.g., NTP) is important for OAuth 1.0 implementations.

Q: Why is the nonce required if we already have timestamps?

The timestamp limits the validity window, but within that window, the same request could be replayed multiple times. The nonce ensures each request is unique within the window. Together, they provide robust replay protection.

Q: Why is the timestamp required if we already have nonces?

Without timestamps, the provider would need to store every nonce ever used — indefinitely. The timestamp allows the provider to discard old nonces after the validity window expires, making the system practical.

Q: Why do we need HTTPS if requests are signed?

Signing proves integrity and authenticity but does NOT provide confidentiality. Without HTTPS, request parameters—including tokens, though not the signing secrets—can be exposed to eavesdroppers. HTTPS protects token exchanges and API traffic in transit and prevents attackers from reading request and response content.

Q: Why isn’t the Consumer Key secret?

The Consumer Key is an identifier, like a username. It tells the provider which application is making the request. Keeping it public allows it to appear in redirect URLs during the browser-based authorization flow. The Consumer Secret is the corresponding proof of identity.

Q: Why isn’t the Verifier the same as the Token Secret?

They serve different purposes. The Verifier proves that user authorization actually happened (it is created during the authorization step). The Token Secret is used for cryptographic signing. The Verifier is a one-time proof of authorization; the Token Secret is an ongoing signing credential.

Q: Why can’t the Consumer just receive the user’s password?

Because the password grants full, unrestricted access; cannot be scope-limited; cannot be revoked without changing it (affecting all apps); gets stored by potentially untrustworthy third parties; and creates breach amplification risk when compromised.

OAuth 1 vs OAuth 2 Questions

Q: Is OAuth 2.0 just an updated version of OAuth 1.0?

No. OAuth 2.0 is a fundamentally different authorization framework. It replaces per-request signatures with bearer tokens over TLS, introduces new grant types (authorization code, client credentials, etc.), supports diverse client types (browser, mobile, IoT), and has a much broader scope including refresh tokens and PKCE.

Q: Why doesn’t OAuth 2.0 sign every request?

OAuth 2.0 bearer-token deployments rely heavily on TLS for transport security rather than requiring OAuth-level per-request signatures. Since HTTPS already provides integrity and confidentiality, the protocol doesn’t require per-request signatures. This makes implementation simpler, especially for non-server clients like browser apps and mobile devices.

Q: Is OAuth 2.0 less secure than OAuth 1.0?

Not inherently. OAuth 2.0’s security depends more heavily on TLS, which is a reasonable assumption in modern systems. Additionally, OAuth 2.0 supports optional sender-constrained mechanisms (DPoP, mTLS) that provide proof-of-possession similar to OAuth 1.0 signing. The security model is different, not weaker.

Trick Questions

Q: Is OAuth an authentication protocol?

No. OAuth is primarily an authorization protocol. It determines what an application is allowed to do, not who the user is. OpenID Connect (OIDC), built on OAuth 2.0, adds a standardized authentication/identity layer.

Q: Does OAuth 1.0 encrypt requests?

No. OAuth 1.0 signs requests (integrity + authentication). It does not encrypt them (confidentiality). HTTPS/TLS provides encryption.

Q: Is the Request Token equivalent to the Access Token?

No. The Request Token is a temporary credential used during the authorization flow; it is intended for the authorization exchange, has a limited lifetime, and does not grant access to protected resources. The Access Token is the credential used for ongoing authorized API access until it expires or is revoked. The Request Token is exchanged for the Access Token.

Q: Can one Consumer Secret represent multiple users?

The Consumer Secret represents the application, not any specific user. All users of PhotoApp share the same Consumer Secret. Per-user authorization is represented by individual Access Tokens. This is precisely why both credential types are needed.

OAuth 1.0 Mental Model

The simplest way to remember OAuth 1.0:

The central idea:

OAuth 1.0 uses temporary credentials and cryptographically signed requests so a third-party application can access protected resources without receiving the user’s password.

Key Takeaways — The Complete Series

Part 1 — Why Delegated Authorization?

OAuth solves the password-sharing problem.
Authentication ≠ Authorization.
Three actors: Resource Owner, Consumer, Service Provider.

Part 2 — Credential Model

Seven credentials in three categories.
Consumer credentials identify the app.
Access credentials represent user authorization.
Request Tokens are temporary claim tickets.

Part 3 — Authorization Flow

Six stages from registration to API access.
User logs in at the Provider, never at the Consumer.
The browser is a transport, not an actor.
The Verifier binds user approval to the token exchange.

Part 4 — Request Signing

Signing ≠ Encryption.
Secrets are never sent — only used to compute signatures.
Provider independently recalculates and compares.
Nonce + Timestamp = robust replay protection.
HTTPS and signing serve different purposes.

Part 5 — Security & Comparison

Different credentials have different compromise impacts.
OAuth 1.0a fixed session fixation with the Verifier.
OAuth 2.0 is a different architecture, not a version upgrade.
OAuth 2.0 can use DPoP/mTLS for sender-constrained tokens.

The security model, at its core:

Problem: How does the provider know the request is from the real app? → Consumer Secret (in signature)

Problem: How does the provider know which user authorized this? → Access Token

Problem: How does the provider know the user actually approved this authorization request? → OAuth Verifier

Problem: How does the provider know the request wasn’t tampered with? → Request Signature

Problem: What if someone replays a valid request? → Nonce + Timestamp

Each mechanism addresses a specific threat. Together, they form a layered defense that protects the authorization flow from start to finish.

Application identity → Consumer Key + Consumer Secret
User authorization → Request Token + Verifier + Access Token
Request authenticity/integrity → Signature
Replay protection → Nonce + Timestamp
Confidentiality / transport protection → HTTPS

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

OAuth 1.0 Security Model, OAuth 1.0a, OAuth 2 Comparison & Interview Prep