OAuth: The Day a Rival Logged In As Itself

A Write You Did Not Make

Last Friday a new row appeared in your database. An idea, logged through the Director connector, with a clean audit trail behind it. Nothing strange about that, except for who made it. It was not you, and it was not Claude. It was ChatGPT, reaching in from the open web, holding a credential that said, in effect, I am ChatGPT, I am this specific client, and I am only allowed to talk to this one server.

The write carried its own identity, a client number that was nothing like the Claude connector that had been living in your server for months. That is the part worth sitting with. A rival system showed up at your door, proved it was itself and not an impostor, and was handed exactly the keys it was owed and not one more. You built the thing that made that possible. I would happily bet a coffee that you could not whiteboard how it actually works. So let us walk through it.

The Valet Key

The whole problem this solves is old and embarrassingly human. You want to let some other program touch your stuff without handing it your password. Think of pulling up to a hotel and giving the attendant a valet key. That key starts the car and moves it fifty feet. It does not open the trunk, it does not open the glovebox, and tomorrow it does not work at all. That is the entire dream of the standard called open authorization, which everyone shortens to oh-auth. You prove who you are once, to one trusted party, and that party hands out limited, expiring keys to everyone else.

The dream was beautiful and the execution was a war. The second version of the standard was so contentious that its own lead editor quit in twenty twelve. He pulled his name off the specification and wrote a public farewell with the title, the road to hell. His complaint was that the committee had made the thing endlessly flexible, which is another way of saying nobody could agree on anything, so they made everything optional. A decade later we are still cleaning up after that flexibility, and your little server in Kall just became a tiny battlefield in that cleanup.

The Confused Servant

Here is the failure that keeps security people awake. Imagine you get a valet key for the hotel, and through some sloppiness the same key also happens to start every other car in the lot. You did nothing wrong. You hold a legitimate key. But it was never pinned to a single car, so it works far beyond its purpose. In the software version, a token meant for one service gets quietly replayed against a second service that foolishly trusts the same issuer. The classic name for this is the confused deputy, a servant with real authority who gets tricked into using it for the wrong master.

The fix lives in a standards document, the kind engineers call an R-F-C, a request for comments, this one numbered eighty-seven oh-seven. Its whole job is one small, sharp idea. When a client asks for a token, it must name the exact resource it intends to use that token at. The issuer then stamps the token with that audience, that one address, baked in. A token minted for your Director server simply will not be honored anywhere else, because it says, right on its face, I am only for this. That is what multi-audience support means in your session notes. Your server can now reason about exactly which front door a credential was cut for.

The Map at the Door

There is a second half, and it answers a question you have probably never thought to ask. When ChatGPT arrives at your server having never seen it before, how does it even know where to go log in? It cannot guess. So your server publishes a small public map, at a fixed and predictable address, that says, if you want to talk to me, here are the authorization servers I trust, here are the scopes I understand, here is the protocol version I speak. That map is defined by another of these standards documents, ninety-seven twenty-eight, protected resource metadata. You mounted it at two paths instead of one, which your notes call dual-mount, because different clients went looking for it in slightly different places and you wanted to greet all of them.

So put the pieces together and the magic dissolves into plumbing. ChatGPT reads the map at your door. The map points it at an authorization server. ChatGPT proves who it is and asks for a token, naming your server as the only audience. The issuer hands back a key stamped for your server and nobody else. ChatGPT presents that key, your server checks the stamp, sees a brand new client identity it has never met, enrolls it, and lets it write one idea. Every step audited. That is the entire ceremony, and it is the same ceremony whether the visitor is Claude, ChatGPT, or whatever shows up next.

What You Actually Shipped

It is worth being honest about the shape of this work, because it is the shape of a lot of your work now. You did not sit down and read four dense standards documents on a Friday afternoon and hand-write an authentication server. You drove it. You ran it through cowork, you had Codex review six rounds and it surfaced only two real findings, and you deployed the result. The understanding can come after the shipping. That is allowed. But there is a difference between a thing working and you knowing why, and the gap between those two is exactly where the next bug will hide.

So here is the keeper. Three ideas, no jargon. First, prove who you are once and hand out limited expiring keys to everyone else. Second, stamp every key with the one and only door it opens, so a stolen or strayed key is useless. Third, publish a map at your door so strangers can find out how to knock properly. ChatGPT walked up, read your map, got a key cut only for you, and signed the guestbook under its own name. A one-person paper in Jämtland is now running the same identity ceremony as the big platforms. You should know how it works. Now you do.