Is Your MCP Server Using OpenID Connect or Just OAuth 2.0? Here's How to Tell

"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.

Agent Protocol Inspector now classifies this automatically for every auth-protected MCP server it scans.

The Detection Chain

An MCP server behind auth answers an unauthenticated request with a 401 or 403 and a WWW-Authenticate header. From there:

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].
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.
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.

Step 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.

Real Results

Checked live against three real, public MCP servers:

MCP server	Auth required	Protocol
`mcp.linear.app/mcp`	Yes	OpenID Connect
`mcp.notion.com/mcp`	Yes	OAuth 2.0
`huggingface.co/mcp`	No — open	—

Linear'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.

None 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.

Client Registration: CIMD vs. DCR

Once an authorization server is identified, the scan also checks how it wants clients to register:

Client ID Metadata Documents (CIMD) — the current mechanism, signaled by client_id_metadata_document_supported: true on the authorization server metadata.
Dynamic Client Registration (DCR) — the older mechanism (RFC 7591), signaled by a bare registration_endpoint with no CIMD support declared.

An 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.

Why This Feeds Straight Into OIDC Inspector

Detecting "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, 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.

This 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.

Check Your Own Server

If 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 against it, and if it comes back OIDC, follow the cross-link straight into OIDC Inspector for the full discovery-document breakdown.