Judge a JWT by its issuer, not its shape

[haruotsu]

Exchanging an authorization code against a Zendesk tenant returns a
JWT-shaped access token: three dot-separated segments, a base64url JSON
header, and claims that carry only exp — no issuer. accepts_token
refused every JWT-shaped token for a prefixless connection, so a Zendesk
authorization could never produce a usable token.

Why shape cannot convict

The refusal exists so that a Google ID token or service account token
handed over by mistake is never sent to an external service. Both are
JWTs — but so are many services' access tokens. "It is a JWT" does not
imply "it is Google's", and the two kinds tell themselves apart by
something no shape check can see: the issuer the claims name.

What is judged now

For a connection without token prefixes (a declared prefix still decides
on its own):

• A JWT that names an issuer is accepted only when the issuer names
  the connection's own service — a host the token may travel to, or the
  host of an OAuth endpoint, since the issuer of a service's tokens is
  its authorization server, which may live beside the API rather than on
  it.
• A JWT that names no issuer says as little about its origin as an
  opaque token, so it is judged like one: by elimination. Zendesk's
  tokens are shaped this way.
• A JWT whose claims cannot be read is refused rather than guessed
  about, exactly as before.

Google's credentials fall out of the first rule without a list of
Google's issuers: ID tokens name accounts.google.com, service account
tokens name the account's own address, and neither is ever the
connection's own host. The signature is deliberately not checked —
nothing here authenticates anyone. The claims are read the way a token
prefix is, to tell whose token this is before it travels; a forged
issuer gains nothing but a request its token cannot answer.

What holds it

• The catalog check that read "a JWT-shaped token is accepted" now holds
  every connection against Google-issued JWTs (ID-token and
  service-account shaped) instead, since an issuerless JWT is exactly
  what a prefixless connection may now accept.
• zendesk.yaml records the observed shape as an accepts example;
  freee and notion-mcp keep refusing Google-issued JWTs in theirs.
• The issuer arrives inside an unvetted token, so one that urlsplit
  cannot read (https://[) is refused instead of raising.