fix(auth): cover the CLI refresh path and tighten the well-known match

Two review findings.

The stored-token refresh path (`refreshStoredAuthToken`) calls SDK discovery
directly rather than through `InspectorClient.effectiveAuthFetch`, so a state
file holding a refresh token and client information but no `serverMetadata`
still hit the upstream OIDC-schema failure and could not refresh against the
very servers this change is for. Its default `discover` now wraps the global
fetch with the compat shim; a caller-supplied `fetchFn` is left alone. Covered
by a test that injects no `discover` — injecting one would bypass the default
under test — against a real server that 404s the RFC 8414 path and serves plain
RFC 8414 metadata at the appended OIDC path.

`oidcDiscoveryCandidates` matched the well-known path by bare prefix, so it
also claimed `/.well-known/oauth-authorization-server-backup` and would have
replaced that path's failed response with a document fetched from a derived
URL. It now requires the exact path or a `/` boundary, which is precisely the
set `buildDiscoveryUrls` can emit.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UL9retfvAXRgvi6EWk4SY4
Signed-off-by: cliffhall <cliff@futurescale.com>
This commit is contained in:
cliffhall 2026-08-28 01:11:51 -04:00
commit 1db1b9be1f

View file

@ -75,6 +75,16 @@ describe("oidcDiscoveryCandidates", () => {
it("returns nothing for an unparseable URL", () => {
expect(oidcDiscoveryCandidates("not a url")).toEqual([]);
});
it("does not claim a path that merely shares the well-known prefix", () => {
// A bare prefix match would treat this as a discovery request and replace
// its failed response with a document from a derived URL (Copilot).
expect(
oidcDiscoveryCandidates(
"https://as.example.com/.well-known/oauth-authorization-server-backup",
),
).toEqual([]);
});
});
describe("isRfc8414OnlyMetadata", () => {