OAuth 1.0 is often remembered as the moment the web finally got a broadly deployable pattern for delegated authorization: a user can let one service access another service on their behalf without handing over a password. But OAuth 1.0 didn’t arrive in the early 1990s. What did exist then was the foundational machinery that made OAuth necessary: HTTP as a simple, stateless interface, early authentication mechanisms that assumed direct user-to-server trust, and the first practical attempts at “sessions” on top of a protocol that didn’t include them.

This chapter focuses on the years 1990–1994, when the Web’s earliest HTTP interfaces took shape and when developers began building what we’d now call API-like behavior—mostly through documents, forms, and CGI scripts. The punchline for OAuth history is not that it existed then, but that the web’s earliest design choices created a long-lived gap: a missing standard way to let one site call another site safely as a user.

1990–1991: A Document Protocol Quietly Becomes an Interface

At the beginning, the Web was about retrieving hypertext documents. Early HTTP was intentionally minimal—good at “fetch this thing,” not at expressing a rich set of operations. Still, the moment you can request a resource by name and get a structured response, you have the seed of an API: a stable contract between a client and a server.

Even in these earliest years, a few properties mattered for the future of API authorization:

• Statelessness: each request stands alone. This is great for scaling and simplicity, but it makes “user is logged in” or “client is authorized” harder without extra mechanisms.
• Uniform addressing: resource naming makes it tempting to build programmatic access around URLs. That temptation becomes irresistible as soon as developers want to automate.
• Text-based messages: readable requests and responses accelerate experimentation, which accelerates accidental API design.

In practice, early “API calls” were often just HTTP requests that returned human-readable content. But the industry was already learning a lesson OAuth would later formalize: when you make it easy to call a server, you also make it easy to misuse credentials.

1992–1993: Early HTTP Servers, Methods, and the Shape of Web Operations

As web servers and browsers spread beyond a small research community, HTTP became more than a document fetch protocol. Implementations began supporting a wider range of needs, including operations that looked less like “read a page” and more like “do a thing.”

The appearance of different HTTP methods (especially the practical use of GET and POST) gave developers a way to express actions. This mattered because authorization is easiest to ignore when everything is just “read,” but becomes unavoidable when you can create, modify, or trigger state changes.

In modern API thinking, we’d say: once you have state-changing operations, you need a coherent model for who is calling, what they can do, and whether they can safely allow a third party to do it for them. In 1992–1993, the Web had not yet standardized that kind of delegated model. Instead, the simplest option tended to win: prompt for a username and password and send them to the server.

Basic Auth: Convenient, Direct, and a Dead End for Delegation

HTTP Basic Authentication was an early, straightforward approach: the client sends credentials (in a simple encoding) to prove identity. It worked well enough for closed environments and quick experiments.

But Basic Auth bakes in a set of assumptions that become problematic the moment you want third-party access:

• Credentials are shared with the caller. If an application needs to call a service “as the user,” it tends to require the user’s password. That is the opposite of OAuth’s goal.
• No fine-grained scopes. Basic Auth generally gives broad access as the user, not limited permissions like “read contacts but not edit.”
• Revocation is blunt. If you shared a password with a third party, the clean revocation method is changing the password, which breaks everything.

In other words, Basic Auth was excellent for a world where the browser and server were the only actors. Delegated authorization requires at least three actors (user, client app, resource server). The early Web’s mainstream patterns didn’t fully embrace that reality yet.

1993–1994: CGI and the First “API Endpoints” Hiding in Plain Sight

One of the biggest steps toward web APIs in this era was the rise of the Common Gateway Interface (CGI). CGI let a web server hand a request to a program, which could generate a response dynamically. This was a major shift: URLs could represent computations, database lookups, and transactions.

From an API-history perspective, CGI scripts often behaved like today’s endpoints:

• They accepted inputs (query parameters or form posts).
• They performed operations (search, update, send a message).
• They returned outputs (HTML then, sometimes machine-friendlier formats later).

CGI also amplified the authorization problem. A CGI endpoint was easy to call from anywhere that could speak HTTP, including scripts, early automation tools, and other servers. Once multiple clients exist, the question becomes: should they all share the same credentials? If a user wants a tool to act on their behalf, how do you do that without giving the tool the keys to the kingdom?

These are precisely the questions OAuth 1.0 eventually answered with tokens and signatures. In 1993–1994, developers solved them ad hoc, often by building application-specific keys, IP allowlists, or simply sharing passwords and hoping for the best.

1994: Cookies, Sessions, and the Move Toward “Delegation-Like” Thinking

HTTP’s stateless design made logins awkward. If the server doesn’t remember you between requests, you need a way to carry state. The introduction and adoption of HTTP cookies (popularized by early browser/server implementations in the mid-1990s) gave developers a practical solution: after a login, the browser stores a small identifier and sends it back automatically.

Cookies weren’t delegated authorization, but they were a major conceptual step toward later token systems:

• They separate the long-term secret from the repeated request credential. The user types a password once; subsequent requests send a session identifier instead of a password.
• They make “token-like” access feel normal. A cookie is effectively a bearer credential in many designs: if you have it, you can act as the user.
• They expose a new threat model. If tokens can be stolen, replayed, or used cross-site, then securing token issuance and usage becomes crucial.

OAuth 1.0’s later emphasis on signed requests and nonces makes more sense against this backdrop: the Web was learning (sometimes the hard way) that reusable credentials traveling over HTTP need careful handling.

Where OAuth 1.0 Fits: Not Here Yet, but Its Requirements Are Being Written

It would be historically inaccurate to place OAuth 1.0 in 1990–1994. What we can place here is the problem statement that OAuth eventually solved. By the mid-1990s, the Web was on a trajectory where:

• Websites were becoming platforms, not just documents.
• Dynamic endpoints were multiplying.
• Users wanted services to interoperate.
• Security patterns were mostly “log in directly” or “share a password.”

Delegated authorization requires a system that can say: “This app is allowed to do this on behalf of the user, and nothing more.” The early Web had identity (logins), and it had state (cookies), but it lacked a common, standardized delegation protocol. When APIs later exploded, the absence of delegation became a major pain point—and OAuth 1.0 became one of the most influential answers.

If you’re building or analyzing modern automation around APIs, it’s useful to remember how old the underlying tensions are. For more applied perspectives on automation and systems behavior, you can also browse related work at AutomatedHacks.com.

A Standards Anchor: HTTP as the Substrate for APIs

Even though the early 1990s were full of experimentation, HTTP’s steady evolution into a widely documented, interoperable protocol is the reason web APIs became the default integration strategy. If you want to connect this early era to today’s standardized view of HTTP, the W3C’s HTTP protocol resources are a solid starting point: https://www.w3.org/Protocols/.

FAQ: OAuth 1.0 and Delegated Authorization in the 1990–1994 Web

Did OAuth 1.0 exist in 1990–1994?

No. OAuth 1.0 was created much later. This period matters because it established HTTP patterns (stateless requests, early auth, sessions) that made delegated authorization a future necessity.

What was the common way to protect early HTTP endpoints?

Basic Authentication and application-specific login flows were common. They worked for direct user-to-site access but didn’t support safe third-party delegation.

Why are cookies relevant to OAuth history?

Cookies normalized the idea of sending a reusable token with each request after a login. OAuth later refined token usage for cross-service delegation and improved control over permissions.

Were CGI scripts early web APIs?

Many behaved like APIs: they accepted parameters, ran server-side logic, and returned results. They weren’t standardized as “APIs,” but functionally they were programmable interfaces over HTTP.