What a Seal Actually Proves

POST /token, 500

The request was a deliberate one: present an already-rotated-away refresh token a second time, the exact scenario a stolen token replay would produce, and confirm the server notices. It noticed. The token family got revoked in the same call. And then the response the caller actually received was this:

✘ [ERROR] Unhandled error: Error: email send failed (422): {"statusCode":422,
"name":"validation_error","message":"Invalid `to` field. The email address
needs to follow the `[email protected]` or `Name <[email protected]>` format."}

POST /token 500 Internal Server Error (181ms)

Not a 400. Not invalid_grant, the response the design specified for exactly this case. A bare 500, because a misconfigured owner-address had made the security team's own alert email fail to send — and that failure, on its way out, had taken the correct rejection down with it.

Ninety-One Tests, and None of Them Had Ever Told the Email to Fail

This was Signet, a small OAuth 2.1 authorization server for a personal fleet of MCP servers, and at the moment that request went out its test suite stood at ninety-one passing tests — domain logic, D1 and KV adapters, and full integration coverage of the flow end to end, including the exact reuse-detection path that had just fired. Every one of those tests was green. Every one of them was also talking to a fake email sender that always succeeded, because nobody had yet had a reason to ask it to do anything else.

That's not a gap in test count. It's the gap between a simulation and the thing it's standing in for. A mock that never fails isn't testing “this handles failure” — it's testing “this handles success,” twice, under two different names. The bug wasn't hiding in a code path nobody had written a test for. It was hiding in a code path everybody had tested, against a double that had never been asked to lie.

One Function, Two Different Kinds of Claim

The handler that caught the reuse hadn't done anything wrong about the security decision itself — the family was revoked, correctly, before the alert was ever sent. The bug was in treating the notification and the rejection as one sequence instead of two independent claims sharing a function by accident:

await this.refreshTokenRepository.revokeFamily(existing.familyId, "reuse_detected", now);
await this.alertNotifier.alert("refresh_token_reuse_detected", { ... }); // ← threw here
throw new OAuthError("invalid_grant", "refresh token has already been used"); // never reached

The fix isn't “add a try/catch.” It's recognizing that these two lines were never actually sequential in the way the code implied — one is the security system doing its job, the other is a courtesy about that job to a human, and the second one's failure has no legitimate claim on the first one's outcome:

// Alerting is a side-channel notification, not part of the security decision — a
// failed email send must never prevent the invalid_grant rejection below from
// reaching the caller. Log and swallow, never rethrow.
await this.alertNotifier
  .alert("refresh_token_reuse_detected", { ... })
  .catch((error) => console.error("Failed to send reuse-detection alert:", error));

throw new OAuthError("invalid_grant", "refresh token has already been used");

Two regression tests went in alongside it — a fake email sender told, for the first time, to actually fail — bringing the suite to ninety-three. Not because the number mattered. Because the thing that had been untested was now the thing being tested.

The Next Morning, a Different Claim

Signet's own documentation describes it as a “spec-compliant OAuth 2.1 Authorization Server,” and that claim had been written down carefully — a table mapping every implemented RFC to the exact file that implements it, checked against real sources the day it was published. The next morning, the same habit got applied a second time: re-read the sources instead of trusting what the table had said twenty-four hours earlier.

The MCP specification had shipped a revision a week before that check — 2026-07-28 — and its changelog contained one line that hadn't been true the day the table was written: authorization servers now had to include an iss parameter on every authorization response, identifying themselves, per RFC 9207. Signet's redirects didn't send one. Fixed the same day it was found, and confirmed against a running instance, not just a green test:

Location: http://localhost:8788/callback?error=invalid_scope&error_description=
resource+%27some-other-server%27+is+not+permitted+for+this+client&state=xyz-state
&iss=https%3A%2F%2Fsignet-dev.example.workers.dev

The specific bug and the specific spec gap have nothing to do with each other. What they share is the only thing that matters here: neither was found by trusting a document written the day before. Both were found by checking again.

What a Seal Actually Proves

A signet ring's entire historical job was pressing a unique mark into warm wax to prove a document was genuine — sealed by a specific hand, at a specific moment, and not tampered with since. Nobody who understood what a wax seal was for ever mistook it for a claim about next month. An intact-looking seal on a letter found a year later tells you the letter wasn't opened after it was sealed. It tells you nothing about whether the hand that sealed it still holds the same authority, whether the signet itself has since been stolen, copied, or retired.

This is also, not incidentally, the reason the project carrying this argument is named what it's named. A signet server issuing signed, audience-bound tokens is doing exactly what a signet ring did — proving, cryptographically, that this specific token was pressed by this specific authority, for this specific recipient, at this specific moment. It was never going to be the part of the system exempt from its own argument.

The General Shape

Green tests are a seal on the claims you thought to make. A spec-compliance table is a seal on the sources as they stood the day you read them. Both are real — the wax was genuinely warm, the mark genuinely pressed by checking, not by assuming. Neither one is a property that persists on its own once the checking stops.

The 500 and the missing iss parameter weren't two unrelated bugs, twenty-four hours apart. They were the same lesson, offered twice in a row, in case the first time didn't take: a seal proves the moment. It was never going to prove the morning after. Only checking again does that — and only for as long as you keep doing it.

Related