MCP OAuth fails RFC 9207 issuer validation — mcp.higgsfield.ai forwards Clerk's iss unmodified

[claaudelane]

Filing here as the public tracker; the defect is in the MCP server at mcp.higgsfield.ai, not the CLI itself.

Symptom

Authorizing the Higgsfield MCP server from an RFC 9207-conforming client (Claude Code) always fails:

Issuer mismatch in authorization response (RFC 9207):
expected "https://mcp.higgsfield.ai", received "https://clerk.higgsfield.ai"

Cause

mcp.higgsfield.ai/.well-known/oauth-authorization-server declares:

{"issuer": "https://mcp.higgsfield.ai",
 "authorization_endpoint": "https://mcp.higgsfield.ai/oauth2/authorize"}

That endpoint is a facade over Clerk — your own protected-resource metadata says so:

{"upstream_authorization_server": "https://clerk.higgsfield.ai"}

And Clerk declares:

{"issuer": "https://clerk.higgsfield.ai",
 "authorization_response_iss_parameter_supported": true}

So Clerk stamps iss=https://clerk.higgsfield.ai into the authorization response, and the facade
forwards that value unmodified to the client's redirect_uri. The client compares the received
issuer against the one it learned from your metadata, finds a mismatch, and refuses.

The observed callback confirms it:

http://localhost:<port>/callback?code=...&iss=https%3A%2F%2Fclerk.higgsfield.ai&state=...

Reproduce

1. Add https://mcp.higgsfield.ai/mcp as an HTTP MCP server in Claude Code.
2. Authenticate.

Fails on every fresh flow (new PKCE challenge and state each time). Removing and re-adding the
server does not help, since the mismatch is recomputed from published metadata on each attempt.

Suggested fix

Any one of:

• rewrite iss to https://mcp.higgsfield.ai in the authorization response, or
• omit the iss parameter, or
• advertise Clerk as the authorization server in your own metadata.

Notes

• The device_code flow via fnf-device-auth.higgsfield.ai is unaffected — it has no authorization
  redirect, so there is no iss to validate.
• A bearer token from an already-authenticated CLI session is accepted by the MCP resource
  (tools/list returns the full surface). That is a usable workaround, not a fix.
• Client-side suppression of RFC 9207 validation would be a security regression, since that check
  is the defense against authorization-server mix-up attacks. The client is behaving correctly here.

[CG6enterprises]

Confirming this reproduces on Claude Code 2.1.239 / MCP SDK OAuth, Windows 11, against a Plus account, as of 2026-08-22. Same mismatch, same empty-token outcome.

One correction to the notes, since it removes the only stated fallback:

The device_code flow via fnf-device-auth.higgsfield.ai is unaffected

That server is advertised in your protected-resource document but is not discoverable. Both metadata paths 404:

$ curl -s https://fnf-device-auth.higgsfield.ai/.well-known/oauth-authorization-server
{"detail":"Not Found"}
$ curl -s https://fnf-device-auth.higgsfield.ai/.well-known/openid-configuration
{"detail":"Not Found"}

So a client that hits the issuer mismatch has no second flow to fall back to, even though /.well-known/oauth-protected-resource/mcp lists fnf-device-auth.higgsfield.ai under authorization_servers and describes a device_code option. Either that endpoint needs to publish metadata, or it should be dropped from the advertised list so clients stop selecting it.

One more observable worth adding: the failed flow still writes a credential record with an empty accessToken, so the server keeps reporting ! Needs authentication and a naive retry re-registers a fresh client each time rather than surfacing the real cause.

Separately, npm i -g @higgsfield/cli + higgsfield auth login works correctly, since that client targets clerk.higgsfield.ai directly and its expected issuer matches what Clerk returns. That is the practical route for Claude Code users landing here until the proxy is fixed.

[paulrobello]

npm i -g @higgsfield/cli + higgsfield auth does not work for me, same unauthorized error

[act2-peter]

Same defect reproduced today (2026-08-25 KST) from two independent MCP clients on macOS, against the same Higgsfield account:

• Claude Code MCP OAuth: Issuer mismatch in authorization response (RFC 9207): expected "https://mcp.higgsfield.ai", received "https://clerk.higgsfield.ai"
• Hermes engine 0.20.5 (hermes mcp login higgsfield): Authentication failed: Authorization response iss mismatch: https://clerk.higgsfield.ai != https://mcp.higgsfield.ai

Details that may help triage:

• Long-lived sessions kept working against the resource server right up until token expiry — last successful tool call through our gateway was 2026-08-24 15:04 UTC (2026-08-25 00:04 KST). Only (re)authorization is broken, consistent with the analysis in this issue.
• As of 2026-08-25 ~01:20 UTC, /.well-known/oauth-authorization-server still declares "issuer": "https://mcp.higgsfield.ai" while the authorization response carries Clerk's iss.
• /.well-known/oauth-protected-resource now advertises higgsfield_auth_hints with a device_code option at https://fnf-device-auth.higgsfield.ai for hermes-class clients, but shipped engine builds do not implement that flow yet, and RFC 9207-compliant authorization_code clients remain hard-blocked.
• Teammates on separate Higgsfield accounts whose tokens have not yet expired are still connected and generating — so the blast radius is "anyone whose token expires from now on".