Authorization discovery and the OAuth boundary

The mechanism

For protected HTTP servers, the MCP authorization framework builds on OAuth. The MCP endpoint is a resource server; an authorization server handles the user authorization flow and issues credentials. Metadata discovery connects these roles, but discovered metadata is still external input that a client must validate.

The modern flow uses protected-resource metadata to identify the resource and its authorization servers. Client registration has several paths; the current specification deprecates dynamic registration as a compatibility mechanism. Do not copy an old tutorial that assumes registration is always open or always required.

ParcelOps should request the narrow capability needed for incident reading. The host must explain the destination and scope before the user grants access. Completing sign-in should not silently authorize later incident writes.

Worked example

This is a review worksheet, not an OAuth request. Values are deliberately placeholders. Use it to verify that the resource, issuer and redirect configuration belong to the intended integration before any browser or token exchange occurs.

{"resource":"https://parcelops.example/mcp",
 "expected_issuer":"https://identity.example",
 "requested_scope":"incident:read",
 "client_registration":"unverified",
 "redirect_uri":"configured-by-approved-client",
 "user_grant":"not_requested"}

Practice: predict, inspect, explain

Offline exercise. Draw the browser, host, MCP endpoint and authorization server. Mark which component receives the authorization code and which receives the access token. Now substitute an unexpected issuer in the metadata and decide where the flow stops.

Expected observation: successful discovery does not automatically make an issuer trusted. Document allowed redirect destinations, exact issuer checks and the resource audience before testing with an approved identity provider. Do not retrieve, paste or store real tokens for this chapter.

Troubleshooting and trade-offs

Repeated sign-in loops can come from issuer mismatch, incorrect redirect configuration or asking for a token meant for another resource. Diagnose those relationships with redacted metadata. Do not broaden scopes or disable validation to make a demo pass. A client-registration method must be supported by the actual provider; protocol documentation is not proof that your tenant enables it.

Interview practice

Completion check

Draw the complete authorization path with the resource and issuer labelled separately.

Sources and version notes

This edition targets MCP 2026-07-28, checked 6 October 2026. SDK examples are version-sensitive and labelled when not executed. Synthetic fixtures are learning material, not protocol conformance evidence.

• Official documentation: Index
• Official documentation: Authorization server discovery
• Official documentation: Client registration