Custom connector OAuth never reaches the IdP: discovery 200, then zero authorize requests (IdP logs confirm) — cluster #479/#582

## Summary

Since **~2026-07-08**, every claude.ai web custom-connector sign-in to our self-hosted MCP gateway (Okta-backed OAuth) fails with the generic toast:

> Authorization with the MCP server failed. You can check your credentials and permissions. If this persists, share this reference with support: `ofid_…`

No Okta sign-in page is ever shown. It had worked for weeks prior with no change on our side. This looks like the same connector-pipeline cluster as #479, #505, #521, #524, #558, #582 — filing with a complementary datapoint from the **identity-provider side** that those reports don't include.

## Reference IDs (multiple failed Connect attempts)
- `ofid_e91f51c5c8c14a8c`
- `ofid_1c742712f1215c1a`
- `ofid_007ce8d73aa0e55d`
- `ofid_3d273aa0523818c3`

## Setup
- Self-hosted MCP server on AWS API Gateway + Lambda, OAuth via a pre-registered Okta OIDC app (authorization_code + PKCE, `client_secret_basic`).
- Server URL: ``
- Auth server (issuer): ``

## Evidence — three independent sources, all consistent

**1. Our IdP (Okta) System Log — the decisive one.** Filtered to the OAuth app for 07-03 → 07-10:
- Last successful `user.authentication.sso` to the app: **2026-07-07 19:37 UTC**, immediately followed by frequent successful sign-ons in the days before (normal working period).
- **07-08, 07-09, 07-10: zero authorize events, zero token grants, zero sign-ons** for the app — during multiple Connect attempts each day. The IdP is simply never asked to authorize.
- A Connect attempt made **with the pre-registered client_id + secret configured** in the connector's Advanced settings still produced **no authorize request** at the IdP.

**2. MCP server logs.** For each failing Connect attempt:
```
POST /mcp 401 (unauthenticated discovery probe — expected)
GET /.well-known/oauth-protected-resource 200 (Claude fetched our metadata successfully)
… then only more unauthenticated probes. A token-bearing request never arrives.
```

**3. Server + IdP health verified in isolation (all pass):**
- `/.well-known/oauth-protected-resource` → 200 with correct `resource` (full URL incl. path) + `authorization_servers`.
- 401 carries a spec-compliant `WWW-Authenticate: Bearer …, resource_metadata="…"` (RFC 9728 / MCP auth 2025-06-18).
- The pre-registered client id + secret authenticate cleanly against the IdP token endpoint (grant_type=authorization_code with a bogus code → `invalid_grant`, i.e. the pair is accepted).
- The IdP `/authorize` endpoint returns a normal sign-in page for this client + the registered `claude.ai` redirect URI.
- Same server connects fine from the **Claude Code CLI** OAuth path.

## Conclusion / ask
The failing flow **never reaches our identity provider**: discovery completes, then Claude issues no authorization request and no token ever reaches the server. This is upstream of the resource server and the IdP — inside claude.ai's connector-authorization pipeline. The exact-boundary timing (last success 07-07 19:37 UTC → zero attempts thereafter) suggests a change shipped around 07-07/07-08.

Could someone trace the `ofid_` references above and confirm where the flow stops on your side (before vs. after the authorize redirect to the IdP)? Happy to provide raw log exports (IdP + server) privately if useful.

Environment: claude.ai web (Enterprise), custom connector, self-hosted MCP over Streamable HTTP.