test(oauth): prove the opt-out against a real authorization server

Copilot review round 3 on #2114.

The unit tests asserted our own `grant_types` array and stopped there.
What actually unblocks an Entra tenant is what the SDK puts in the
authorize URL, and nothing covered that — so an SDK change that stopped
keying its augmentation off `grant_types` would leave AADSTS90094
intact with every test green.

Adds the complementary case to the existing e2e suite, against a real
AS advertising `offline_access`: with the grant declined, the authorize
URL carries neither `offline_access` nor `prompt=consent`, while the
configured scope still goes out. Verified non-vacuous by reverting the
provider conditional — it fails. The positive test alongside it now
also asserts `prompt=consent` is present, which was unasserted despite
being the literal failure in the issue.

Drops an unjustified `as unknown as ServerEntry` I added in the App
test — AGENTS.md forbids it, and it hid a real mismatch (a partial
settings object against a complete one). Typed `ServerEntry` /
`InspectorServerSettings` fixtures instead, so a field added to that
interface later is a compile error rather than a missing value at
runtime. The `constructedOAuth` helper reads through the constructor's
own parameter type and needs no cast at all now.

Scopes the two doc comments that still claimed the flag removes every
`offline_access` — `StoredMCPServer.oauth` and `OAuthProviderConfig`,
both contradicting the caveat already stated elsewhere.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013hzwzS8UvBsr4yZm7o7sev
Signed-off-by: cliffhall <cliff@futurescale.com>
This commit is contained in:
cliffhall 2026-08-24 21:03:41 -04:00
commit 6303f8a6ce
2 changed files with 125 additions and 22 deletions

View file

@ -116,8 +116,13 @@ export type OAuthProviderConfig = {
* `startAuthorization()` then appends `prompt=consent` whenever
* `offline_access` is in scope. Against Microsoft Entra ID, that forced
* consent prompt routes a non-admin user into the admin-consent workflow and
* fails with `AADSTS90094` even after a tenant admin has consented. Dropping
* the grant here breaks that chain at its source.
* fails with `AADSTS90094` even after a tenant admin has consented.
*
* It removes that *automatic* augmentation only. `startAuthorization()` reads
* the scope, never `grant_types`, so an `offline_access` the caller passed in
* `scope` — or one the resource advertises when `scope` is unset, which
* `determineScope` falls back to — still produces the prompt. This is not on
* its own a guarantee that `prompt=consent` is absent.
*/
requestRefreshToken?: boolean;
};
@ -205,9 +210,10 @@ export class BaseOAuthClientProvider implements OAuthClientProvider {
redirect_uris: this.redirect_uris,
token_endpoint_auth_method: "none",
// #2068: `refresh_token` is declared by default, and dropped when the
// server's "Request refresh token" setting is off — which also stops the
// SDK adding `offline_access` (and therefore `prompt=consent`) to the
// authorization request. See `OAuthProviderConfig.requestRefreshToken`.
// server's "Request refresh token" setting is off — which stops the SDK
// *adding* `offline_access` (and so the `prompt=consent` it forces). It
// does not remove an `offline_access` that reaches the scope another way.
// See `OAuthProviderConfig.requestRefreshToken`.
grant_types: this.requestRefreshToken
? ["authorization_code", "refresh_token"]
: ["authorization_code"],

View file

@ -184,9 +184,12 @@ export type StoredMCPServer = MCPServerConfig & {
* Whether the Inspector declares the `refresh_token` grant when it
* registers. Defaults to `true`; only `false` is written to disk, so an
* entry that never touched the setting keeps a minimal diff. Turning it off
* also stops the SDK adding `offline_access` to the requested scope and
* `prompt=consent` to the authorization request. Inspector-specific.
* (#2068)
* stops the SDK's *automatic* `offline_access` augmentation, and so the
* `prompt=consent` that scope forces — but only that one: an
* `offline_access` from `scopes` here, or from the resource's advertised
* scopes when `scopes` is unset, still reaches the authorization request.
* See {@link InspectorServerSettings.oauthRequestRefreshToken}.
* Inspector-specific. (#2068)
*/
requestRefreshToken?: boolean;
/**