When developers talk about modern API authorization, the conversation quickly turns to OAuth 2.0: access tokens, scopes, consent screens, and third-party apps that can act on your behalf without learning your password. It’s so common today that it’s easy to forget how unusual that model would have seemed at the birth of the Web.

From roughly 1990 through 1994, the Web’s core building blocks were still being invented in public. HTTP existed primarily to fetch and display documents. Servers were often academic or institutional systems hosting static files. The “interfaces” you interacted with were mostly HTML pages and, increasingly, simple server-side programs. In that world, authorization existed—but it was closer to “can you read this directory?” than “can this app access my calendar data for the next hour?”

This chapter looks at what early HTTP interfaces could and couldn’t do, how people thought about authentication and access control in those years, and why those constraints quietly set the stage for the much later emergence of OAuth 2.0 as a standard approach to delegated authorization.

The Web’s First Interfaces: Documents First, Integration Later

The early Web treated the network as a giant hypertext filesystem. You requested a resource (often an HTML document), and you got it. “APIs” in the modern sense—stable machine-oriented endpoints meant for automation and integration—weren’t a mainstream concept on the Web yet.

But something important was happening: once you have a simple request/response protocol, you have the skeleton of a programmable interface. Early servers and early clients didn’t label it that way, yet the shape was already there:

• Uniform resource identifiers made resources addressable.
• HTTP requests created a standard way to retrieve those resources.
• Server logs and access controls pushed administrators to decide who could fetch what.

In other words, the Web was accidentally becoming an integration platform—long before it admitted that was part of the job.

What “Authorization” Meant in 1990–1994

In the early 1990s, authorization was mostly about controlling access to documents. The problem statement was usually institutional: protect internal research pages, limit who can download a file, or restrict admin areas on a server.

In that environment, a few patterns emerged:

1) Network-based trust

Many systems relied on assumptions like “people on this network are trusted.” Firewalls and internal networks were often treated as the boundary. That is a form of authorization, but it is coarse: it authorizes locations, not users or applications.

2) Password prompts and shared secrets

As HTTP authorization mechanisms evolved, the earliest widely recognized approach was what would later be standardized as HTTP Basic Authentication. Conceptually it was simple: the browser prompts for a username and password, and subsequent requests include credentials. In the early Web, this matched how administrators already thought—users have accounts, accounts have passwords, and the server decides what each account can access.

Even when used carefully, this model has a limitation that matters for API history: it does not separate the user from the software acting for the user. If a script needs access, it either stores a password (dangerous) or it cannot act independently (inconvenient). OAuth’s later premise—“let an app get limited access without getting the password”—was not yet culturally or technically normal.

3) The rise of server-side programs (proto-APIs)

As servers became more capable and dynamic content became desirable, web servers gained ways to execute programs and generate responses. The Common Gateway Interface (CGI) became an early mechanism for “run code when a URL is requested.” Developers could now build interactive forms, search endpoints, counters, and gateways to databases—still often presented as HTML, but increasingly representing data and actions.

This shift mattered for authorization because once a URL triggers an action (not just a file read), questions multiply:

• Who is allowed to perform the action?
• How do you log and audit it?
• How do you avoid leaking user credentials to scripts, proxies, or logs?
• How do you authorize a third-party program to act with limited privileges?

Those are “API authorization” questions, even if nobody in 1993 called them that.

The Missing Pieces That OAuth 2.0 Later Supplied

To understand OAuth 2.0’s role in web API history, it helps to name what early HTTP interfaces lacked. Between 1990 and 1994, the Web did not have a standardized toolbox for delegated authorization. Specifically:

No standard way to delegate

Delegation means: “I (the user) want to allow this application to do that against that service, without giving away my primary credentials.” Early web authentication was closer to “prove you are Alice” than “prove you are an app that Alice authorized.”

No token culture

Modern APIs use tokens everywhere: bearer tokens, refresh tokens, short lifetimes, rotation, revocation, and scopes. Early HTTP access patterns largely assumed longer-lived secrets (passwords) and did not have a ubiquitous, standardized concept of short-lived, limited-scope credentials for HTTP requests.

No user consent UX pattern

OAuth’s most recognizable user experience—being redirected to a trusted authorization server, logging in, and granting consent—only makes sense once you have a web full of multi-site apps and a strong separation between identity, authorization, and resource hosting. In 1990–1994, the Web was still small enough that “just use your account on this server” felt normal.

How Early Constraints Shaped Later API Security Thinking

It’s tempting to view early Web authorization as “primitive,” but historically it was also honest: it reflected what the Web was. The Web started as a document system, so access control started as a document problem.

However, the moment server-side programs became common, the Web began inching toward something like today’s APIs: endpoints that return computed results, update state, and integrate with other systems. That transition exposed a gap: password-based, server-local authorization did not scale to a world of cross-site integrations.

If you’ve ever built a modern API and debated whether to use OAuth 2.0, API keys, signed requests, or session cookies, you’re participating in a long arc of web API history. The earliest years didn’t have the vocabulary, but they created the pressure that made new vocabulary necessary.

One practical way to see this arc is to compare the “unit of trust”:

• Early Web: trust the network, then trust the user’s password to access a resource.
• Modern API ecosystems: trust an authorization server to issue limited tokens to a client for a specific resource and scope.

That second model is the world OAuth 2.0 formalized. For the canonical specification, see the OAuth 2.0 Authorization Framework in RFC 6749.

What This Means for Developers Studying Web API History

Looking back at 1990–1994 clarifies a key lesson: authorization systems tend to follow architecture. When your web server is mostly serving files, authorization is directory-level and identity-centric. When your web server becomes a platform for third-party applications and distributed services, authorization becomes token-centric and delegation-centric.

That’s why OAuth 2.0 belongs in a history chapter about the earliest HTTP interfaces—even though OAuth itself came much later. The early years explain the baseline assumptions OAuth had to break:

• Stop sharing passwords with anything that needs access.
• Stop treating a browser prompt as the only authentication UX.
• Start treating authorization as an explicit, limited grant.

If you’re mapping these historical patterns to modern automation and API workflows, you may also enjoy related security and engineering write-ups at https://automatedhacks.com/.

FAQ: Early Web Authorization and the Road to OAuth 2.0