fix(auth): never apply endpoint overrides on the enterprise-managed leg

The overrides are per-server configuration for the *resource* server's
authorization server, but the fetch wrapper that applies them is shared
with the enterprise-managed (EMA) flow, whose IdP OIDC discovery runs
through the same fetch and satisfies the metadata predicate. An
authorization override could therefore redirect the IdP login to the
resource AS, and a token override could send the IdP code or refresh
token there.

OAuthManager.getEndpointOverrides() now returns nothing when the server
is enterprise-managed — the same boundary redirectToExternalAuthorization
draws for the custom authorization parameters (#2018) — with a regression
test, the note surfaced on both form fields, and the rule documented.

Signed-off-by: cliffhall <cliff@futurescale.com>
This commit is contained in:
cliffhall 2026-08-16 21:13:51 -04:00
commit 05698647f8

View file

@ -114,8 +114,18 @@ export class OAuthManager {
* `setOAuthConfig` between requests takes effect without rebuilding the
* client's fetch. `InspectorClient` reads this from inside its fetch wrapper.
* (#1906)
*
* Returns nothing under enterprise-managed authorization, for the same reason
* `redirectToExternalAuthorization` skips the custom authorization parameters
* (#2018): the EMA leg authorizes against the enterprise IdP, a *different*
* authorization server, and its OIDC discovery runs through this same fetch
* (`emaFlow` → `idpOidc`). Rewriting that document would point the IdP login —
* or the IdP code/refresh-token exchange — at the resource server's
* authorization server, which is both wrong and a way to leak an IdP
* credential across an authorization-server boundary.
*/
getEndpointOverrides(): OAuthEndpointOverrides | undefined {
if (this.isEnterpriseManaged()) return undefined;
const { authorizationUrl, tokenUrl } = this.oauthConfig;
if (!authorizationUrl && !tokenUrl) return undefined;
return {