{"slug": "is-your-mcp-server-using-openid-connect-or-just-oauth-2-0-here-s-how-to-tell", "title": "Is Your MCP Server Using OpenID Connect or Just OAuth 2.0? Here's How to Tell", "summary": "Agent Protocol Inspector now automatically classifies whether an auth-protected MCP server's authorization server is a full OpenID Connect provider or bare OAuth 2.0, using RFC 9728 protected resource metadata and independent RFC 8414 discovery requests. Live scans found Linear's MCP server (mcp.linear.app/mcp) is OpenID Connect, Notion's (mcp.notion.com/mcp) is bare OAuth 2.0, and Hugging Face's (huggingface.co/mcp) requires no authentication. The tool's earlier `??` fallback bug checked OAuth metadata first and only fell back to the OIDC document, so issuers serving both documents always classified as OAuth 2.0; fetching both documents independently fixes the misclassification.", "body_md": "# Is Your MCP Server Using OpenID Connect or Just OAuth 2.0? Here's How to Tell\n\nHow to detect whether an MCP server's authorization server is a full OpenID Connect provider or bare OAuth 2.0, using RFC 9728 and RFC 8414 discovery — with real results from Linear, Notion, and Hugging Face.\n\n\"This MCP server requires OAuth\" is true of most production MCP deployments today, and it's also not the full story. Some of those authorization servers are complete OpenID Connect providers — they issue ID tokens, publish standard claims, and can be treated as first-class identity sources. Others speak bare OAuth 2.0 with no identity layer at all. The difference decides whether you can layer identity-aware policy, standard claim mapping, and existing OIDC tooling on top of an MCP integration, or whether you're stuck treating the authorization server as an opaque token issuer.\n\nAgent Protocol Inspector now classifies this automatically for every auth-protected MCP server it scans.\n\n## The Detection Chain\n\nAn MCP server behind auth answers an unauthenticated request with a `401` or `403` and a `WWW-Authenticate` header. From there:\n\n1. **Find the issuer.** Parse`resource_metadata` out of the challenge (or check`/.well-known/oauth-protected-resource` directly) — this is RFC 9728's protected resource metadata, and it names the authorization server in`authorization_servers[0]` .\n2. **Check both discovery documents, independently.** At that issuer's origin, fetch`/.well-known/openid-configuration`*and*`/.well-known/oauth-authorization-server` (the RFC 8414 authorization server metadata document) — as two separate requests, not one as a fallback for the other.\n3. **Classify.** If the OpenID Connect document resolves, the issuer is OIDC. If only the OAuth document resolves, it's bare OAuth 2.0. If neither resolves despite an issuer being declared, it's reported as unconfirmed rather than guessed.\n\nStep 2's independence is the part that's easy to get wrong, and worth naming plainly since it was a real bug in an earlier version of this exact scanner: checking the two documents with an `??` fallback — try OAuth metadata, fall back to OIDC only if that fails — means an issuer that serves *both* documents (a common, spec-compliant setup) never gets its OIDC-specific document checked at all. It would always classify as \"OAuth 2.0,\" even for a genuine OpenID Connect provider. The fix is simply not treating one check as a fallback for the other — fetch both, and let whichever one actually resolves decide the classification.\n\n## Real Results\n\nChecked live against three real, public MCP servers:\n\n| MCP server | Auth required | Protocol | \n|---|---|---|\n| `mcp.linear.app/mcp` | Yes | **OpenID Connect** | \n| `mcp.notion.com/mcp` | Yes | OAuth 2.0 | \n| `huggingface.co/mcp` | No — open | — | \n\nLinear's MCP server is a genuine OpenID Connect provider — before the independence fix above, a scanner using the fallback pattern would have missed that entirely and reported it as plain OAuth. Notion's is bare OAuth 2.0: a real, correctly implemented authorization server, just without the identity layer on top. Hugging Face's MCP server answers with no authentication challenge at all, which is its own useful signal — an \"open\" MCP server is exactly as easy to detect and worth recording as a protected one.\n\nNone of this is a criticism of any of these implementations — OAuth 2.0 without OIDC is a completely valid, spec-compliant choice when identity claims aren't needed for the use case. The point is that \"requires OAuth\" alone doesn't tell an integrator or a security reviewer which of these they're actually looking at, and until now, most scanners couldn't reliably tell them apart either.\n\n## Client Registration: CIMD vs. DCR\n\nOnce an authorization server is identified, the scan also checks how it wants clients to register:\n\n- **Client ID Metadata Documents (CIMD)** — the current mechanism, signaled by`client_id_metadata_document_supported: true` on the authorization server metadata.\n- **Dynamic Client Registration (DCR)** — the older mechanism (RFC 7591), signaled by a bare`registration_endpoint` with no CIMD support declared.\n\nAn authorization server that only supports DCR gets a specific warning, since CIMD is the mechanism current MCP clients should be able to rely on going forward.\n\n## Why This Feeds Straight Into OIDC Inspector\n\nDetecting \"this is OpenID Connect\" is more useful when the next step is one click away. As soon as Agent Protocol Inspector classifies an MCP server's issuer as OIDC, it surfaces a direct cross-link into [OIDC Inspector](https://contextiq.trango-compute.com/oidc-inspector), pre-filled with that issuer URL — no copying a URL out of a JSON blob and pasting it somewhere else. OIDC Inspector then does the deeper pass: supported signing algorithms, PKCE enforcement, and Cross-App Access (ID-JAG) support, the same discovery-document analysis you'd run on any other OIDC provider.\n\nThis mirrors a pattern Agent Protocol Inspector already used for A2A agent cards that declare an `openIdConnectUrl` in their security schemes — the same one-click handoff, just extended to cover MCP's own auth discovery chain.\n\n## Check Your Own Server\n\nIf you run an MCP server behind OAuth, it's worth knowing which of these two categories your own authorization server actually falls into — particularly if you're planning to add identity-aware features later and assumed OIDC was already available. Run [Agent Protocol Inspector](https://contextiq.trango-compute.com/agent-readiness-detector) against it, and if it comes back OIDC, follow the cross-link straight into [OIDC Inspector](https://contextiq.trango-compute.com/oidc-inspector) for the full discovery-document breakdown.\n\nFollow Trango Compute on LinkedIn\n\nWe post updates on new tools, context engineering patterns, and LLM cost research.\n\n[Follow on LinkedIn](https://www.linkedin.com/company/trango-compute)", "url": "https://wpnews.pro/news/is-your-mcp-server-using-openid-connect-or-just-oauth-2-0-here-s-how-to-tell", "canonical_source": "https://contextiq.trango-compute.com/blog/mcp-server-openid-connect-oauth2-detection", "published_at": "2026-09-18 00:00:00+00:00", "updated_at": "2026-09-28 15:19:46.691959+00:00", "lang": "en", "topics": ["agent-protocols", "ai-agents", "developer-tools", "ai-tools"], "entities": ["Agent Protocol Inspector", "Linear", "Notion", "Hugging Face", "OpenID Connect", "OAuth 2.0", "RFC 9728", "RFC 8414"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/is-your-mcp-server-using-openid-connect-or-just-oauth-2-0-here-s-how-to-tell", "markdown": "https://wpnews.pro/news/is-your-mcp-server-using-openid-connect-or-just-oauth-2-0-here-s-how-to-tell.md", "text": "https://wpnews.pro/news/is-your-mcp-server-using-openid-connect-or-just-oauth-2-0-here-s-how-to-tell.txt", "jsonld": "https://wpnews.pro/news/is-your-mcp-server-using-openid-connect-or-just-oauth-2-0-here-s-how-to-tell.jsonld"}}