JWTs (JSON Web Tokens) are a modern answer to a timeless web problem: how does a server authenticate a request in a way that works across clients, scales across machines, and doesn’t force fragile statefulness onto every hop?

But if you rewind to the Web’s earliest period—roughly 1990 through 1994—you won’t find JWTs, OAuth, or even the API vocabulary we use today. What you will find is a set of constraints and early design patterns that practically forecast why token-based API authentication became inevitable. This is Chapter 47 in our chronological history of web APIs: the birth of the Web and early HTTP interfaces, where authentication was still being invented in real time.

1990–1991: When “API calls” were just documents (and HTTP was tiny)

The earliest Web servers and clients were built for retrieving hypertext documents, not for integrating services. Early HTTP (often referred to as HTTP/0.9 in retrospectives) was extremely simple: a client sent a request line, and the server returned a response body. There were few, if any, standardized headers, and therefore very limited room for a reusable authentication envelope.

In that world, “authentication” tended to be out-of-band (network access controls, trusted environments) or implemented in application-specific ways. If you wanted to gate access, you might rely on server configuration, IP-based restrictions, or custom solutions at the application layer. That matters for API history because it shows the starting point: a stateless request/response protocol with almost no standardized metadata for credentials.

Even then, the fundamental tension was present. HTTP’s statelessness made it easy for clients to connect and for servers to scale, but it made user identity hard to carry across multiple requests. That is the same tension JWT addresses decades later—just with different tools.

1992–1993: Gateways, CGI, and the first “service-like” HTTP interfaces

As the Web spread, developers began using HTTP as a general interface to do things, not just fetch pages. The Common Gateway Interface (CGI) became a major bridge between web servers and programs that could generate dynamic output. Once a URL could trigger code, the Web started to resemble an application platform.

This is a key moment in web API history. Many CGI endpoints behaved like early web APIs: they accepted inputs via query strings or form posts and returned machine-parseable output (sometimes plain text, sometimes HTML, sometimes ad hoc formats). But CGI also highlighted a major authentication problem: every HTTP request could start a fresh process. Where do you keep identity, permissions, and session state?

The common answer was to invent “tokens” that were not yet called tokens:

• Opaque session identifiers stored server-side and passed back and forth.
• Credential caching inside browsers or clients using Basic authentication mechanisms (where supported).
• Query-string keys appended to URLs (a pattern that worked, but leaked easily via logs and referrers).
• Hidden form fields carrying state through user flows when client storage was limited.

None of these were JWTs. But they are clearly token-based patterns: a short string stands in for identity and authorization context, and the server uses that string to decide what happens next.

Basic Auth and the earliest standardized credential envelope

By the early 1990s, browser and server implementations were converging toward HTTP with richer semantics: status codes, headers, and reusable authentication challenges. “Basic” authentication (username and password conveyed in a simple encoded form) became the first widely recognized HTTP-level credential envelope.

From a modern security perspective, Basic auth has obvious weaknesses, especially without transport encryption. But historically, it introduced something critical for API evolution:

• A consistent place for credentials: the request headers, not the URL.
• A consistent failure flow: the server returns an authentication challenge and the client retries.
• A realm concept: a way to scope credentials to a protected area.

This “standard envelope” idea is one of the roots of modern API authentication schemes. JWT ultimately fits into the same envelope concept (a header-delivered credential), even though its cryptographic goals and claims-based model are much more advanced.

1994: Cookies arrive and make state portable (but also messy)

Around 1994, cookies began to emerge in mainstream browser/server practice, allowing a server to set a small piece of client-stored state that would be sent back automatically on subsequent requests. For authentication, cookies were a breakthrough: rather than forcing credentials to be re-sent each time, the server could mint a session identifier and rely on the browser to replay it.

This is arguably the first mass-market “token replay” mechanism on the Web: the cookie value is an opaque token that maps to server-side session state. Many early sites used it to implement login, shopping carts, and personalization. The Web didn’t call it token-based API authentication yet, but the pattern is unmistakable.

However, cookies also tied identity tightly to browser behavior and same-origin conventions. For early web APIs—especially those consumed by scripts, gateways, or non-browser clients—cookies were not always a clean fit. This gap pushed developers toward other token-like methods for programmatic access: API keys in parameters, per-client secrets, and later header-based schemes.

So where does JWT fit into a 1990–1994 story?

JWT is much later than this chapter’s era, so it would be inaccurate to imply otherwise. What is accurate is that JWT’s design answers problems that became visible as soon as HTTP was used as a general interface:

Problem 1: Stateless requests vs. user identity

HTTP made scaling and caching possible by being stateless, but applications immediately wanted continuity: “this user is logged in” and “this request is allowed.” Early solutions stored session state on the server and passed around opaque IDs (cookies, hidden fields, query strings). JWT flips that: it packages claims into a signed token so the server can validate without looking up session state on every request.

Problem 2: Portability across clients

In 1990–1994, browsers were the dominant clients, and many authentication patterns assumed browser behavior. As web APIs matured, more clients appeared: scripts, mobile apps, service-to-service calls. Token formats needed to be portable, standardized, and easy to attach to HTTP requests. The early Web laid the groundwork by normalizing headers, status codes, and the concept of a reusable authentication challenge.

Problem 3: Trust boundaries and intermediaries

Even early on, the Web included proxies, gateways, and shared infrastructure. When more than one server might handle a request, centralized server-side session state becomes complicated. The instinct to “carry a proof of authorization with the request” shows up early in ad hoc tokens and later becomes formalized in signed tokens like JWT.

Early lessons that still apply to modern API authentication

If you build APIs today, you can still see the fingerprints of 1990–1994 design constraints in your daily decisions:

1. Don’t put secrets in URLs. Early query-string credential patterns were convenient but leaky. Modern best practice favors headers (for bearer tokens) and secure storage.
2. Standard envelopes scale. Basic auth popularized “credentials belong in headers.” JWT and other bearer tokens follow that same spirit.
3. Client behavior matters. Cookies made browsers powerful API consumers but complicated cross-site and non-browser use cases. Many API designs now separate browser session auth from programmatic token auth.
4. Statelessness is a tradeoff. JWT reduces server lookups but introduces token lifetime, revocation, and key rotation complexity. Those are the modern echoes of early session-state challenges.

If you’re exploring automation, testing, or security research around authentication flows, you may also enjoy related material at https://automatedhacks.com/.

A quick standards reference (and why it matters)

While this chapter focuses on 1990–1994, the Web’s rapid growth soon drove formal standardization of HTTP semantics that underpin API authentication today. A useful reference point is the HTTP/1.0 specification, which captures many conventions (methods, headers, status codes) that made interoperable API design practical across vendors and implementations. See: https://www.rfc-editor.org/rfc/rfc1945.

The key takeaway for API history is that authentication isn’t just a security feature—it’s an interoperability feature. The early Web learned that lesson the hard way, and JWT is part of the modern, standardized response.

FAQ: JWT and token-based authentication in the early Web

Did JWT exist between 1990 and 1994?

No. JWT is a much later technology. This chapter explains the early HTTP and web application patterns that created the need for portable, token-based authentication schemes.

What counted as a “token” in early web API-like systems?

Common examples included opaque session IDs (often carried in early cookie implementations), query-string keys, and hidden form fields that preserved state across multiple requests.

Why was Basic authentication important for API history?

It helped normalize the idea that credentials should be carried in HTTP headers with a consistent challenge/response flow, which later made modern header-based token schemes feel natural.

What was the biggest authentication limitation of the early Web?

HTTP’s statelessness made identity continuity difficult. Early approaches either re-sent credentials repeatedly or created server-side sessions and passed a short identifier back and forth.