Authenticate Entra ID marketplace API requests via RFC 9728 PRM negotiation - #325804

Scope: Microsoft Entra ID only. The GitHub auth-enabled path called for in #325412 — RFC 8693 token exchange at the deployment's embedded Authorization Server, onDidChangeSessions('github') invalidation, and the GitHub test scenarios — is deferred to a follow-up PR. The GitHub path here is unchanged: it carries no bearer at all.

Builds on #325331 (now merged), which added Microsoft Entra ID sign-in as a licensing signal for a Private Marketplace but left the token it produced unused. Partially addresses #325412.

Why

A Private Marketplace running with authentication enforced refuses its service index outright unless a token minted for the marketplace itself is presented. Signing in is not enough: the sign-in token identifies the user, but its audience is not the marketplace.

The marketplace's resource identity cannot be shipped in product.json, because a self-hosted deployment has its own app registration and its own scopes — one value baked into the build cannot serve every enterprise. So the client has to learn it from the resource at runtime, which is exactly what RFC 9728 exists for.

What it does

1. Read the service index with whatever bearer the account already carries.
2. If the marketplace refuses it (401/403), read the Protected Resource Metadata it advertises at /.well-known/oauth-protected-resource to learn its authorization server and scopes.
3. Ask the account for a resource-scoped token against that server (RFC 8707) and read the index again.
4. Attach the accepted bearer to the requests that follow — extensionquery/search, control manifest, asset and VSIX downloads, extension resources (icons, README incl. embedded images, CHANGELOG), and the shared-process getManifest/VSIX path.

Whether a marketplace needs any of this is discovered, not configured: one that accepts what it is given is never asked what a token for it should look like, and never has the well-known endpoint fetched.

Discovery uses the well-known endpoint rather than the WWW-Authenticate challenge, because that header is not CORS-safelisted and the renderer's cross-origin index fetch usually cannot read it. The challenge is used only as a hint for an explicit resource_metadata URL.

Which origins may receive the bearer

IExtensionGalleryManifestService.getAccessToken() is replaced by:

getAuthorizationHeaders(targetUrl: string): Promise<Record<string, string>>;

Callers ask for headers instead of handling a raw token, so the rule deciding which origins may receive the bearer has one implementation, in the platform base class.

The rule is strict same-origin over https against the service index — the endpoint that demanded the token and that it was minted for — and it fails closed. This matters concretely: a marketplace serves assets from its own origin when proxying, but upstreamed extensions are fetched from the public Microsoft marketplace, which must never receive a private marketplace's Entra token. A parent-domain suffix match would be unsafe here, since these deployments can share a domain with unrelated tenants.

The bearer is dropped whenever the marketplace is retracted, so a sign-out, account switch, or configuration change cannot leave a usable one behind.

Commits

1. Negotiate a resource-scoped token when the marketplace gates its index — discovery, negotiation, retry, and the origin rule.
2. Authenticate the gallery API requests — search, control manifest, asset and VSIX downloads.
3. Authenticate the extension resource requests — icons, README, CHANGELOG.
4. Authenticate the marketplace requests the shared process makes — that process cannot negotiate, so the token and the index origin travel with the manifest over the existing channel.
5. Consent to the marketplace resource during interactive sign-in — the access check is silent by contract and cannot prompt.
6. Cover the gated service index — tests.

Behavior notes for reviewers

• A marketplace that still refuses after negotiation now reports RequiresSignIn, not AccessDenied. AccessDenied renders as "contact your administrator" with no action; a missing consent grant is resolvable by the user, so sending them there was a dead end.
• The bearer now also reaches the remote server, not just the shared process — both receive it over the manifest channel. The origin rule is applied identically in that process.
• Open and public marketplaces are unaffected. No token is negotiated, none is attached, and the well-known endpoint is never fetched.

Testing

• Unit tests cover the negotiation and the origin rule: reaching the marketplace through negotiation, skipping it when the marketplace accepts what it's given, refusing when no resource is advertised, dropping the bearer on retraction, and withholding it from a foreign origin, a parent-domain neighbour, cleartext, and an unparseable URL.
• New extensionGalleryManifestServiceIpc.test.ts covers the cross-process channel, which is the one path where an argument-order mistake would silently leak or drop the bearer.
• A manual pass against a Private Marketplace with authentication enforced is still worth doing before merge — see the test plan.