> ## Documentation Index
> Fetch the complete documentation index at: https://tyk-joancamostyk-patch-19.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Access Protected MCP Proxies with OAuth 2.1

> How the Developer Portal surfaces Protected Resource Metadata and issues credentials for OAuth 2.1-protected MCP proxies, including secret-less PKCE clients.

## Availability

| Component        | Version | Editions   |
| :--------------- | :------ | :--------- |
| Developer Portal | v1.19.0 | Enterprise |

## Overview

An MCP proxy can be protected using OAuth 2.1 and Protected Resource Metadata (PRM, [RFC 9728](https://www.rfc-editor.org/rfc/rfc9728)). PRM tells an MCP client where to obtain a token and for which resource. The Developer Portal surfaces this metadata so a developer who has been granted access to a Product can find out how to get a working token, without needing it explained by the platform team.

## Prerequisites

This page describes what a developer sees. It assumes your organization already has:

* Developer Portal v1.19.0 or later
* At least one Product containing a PRM-protected MCP proxy, published to a Catalog

To follow the steps on this page yourself, you need:

* A [Developer App](/portal/developer-app) with an approved subscription to a Product containing a PRM-protected MCP proxy. See [Request access to an API](/portal/request-access) if you haven't done this yet.

## Mirror and Static PRM

A PRM-protected MCP proxy is configured in one of two modes:

* **Mirror mode**: the Portal shows runtime-discovery guidance rather than a fixed authorization server, since the correct authorization server is resolved dynamically.
* **Static mode**: the Portal shows the configured resource, authorization server, and scopes directly.

## Where Developers Find Token Information

Once a developer's Developer App is approved for a Product containing a PRM-protected MCP proxy, both the Product's detail page and the issued credential's card show a "where to get a token" section for that proxy: the resource, the authorization server, and the required scopes. In mirror mode, this section shows discovery guidance instead of a fixed authorization server value. The section gives you what you need to build a token request against your authorization server yourself, together with the Client ID and Secret shown elsewhere on the card - it does not provide a runnable command.

## Clients That Can't Hold a Secret

Some MCP clients, such as VS Code, cannot hold a client secret. For these, the Portal can issue a credential with no secret through Dynamic Client Registration, secured with PKCE instead. When a credential is issued this way, its credential card shows PKCE connection guidance in place of a secret field.

## Scopes

If the underlying API requires specific OAuth 2.0 scopes, those scopes are included automatically in the token issued for the credential. The credential card shows the scopes that apply, read-only.

## Known Limitation

In static mode, the Portal does not validate the configured authorization server. If it is set incorrectly, the error only appears when a client attempts to exchange a token, not when the configuration is saved.

## Troubleshooting

<AccordionGroup>
  <Accordion title="An MCP client that cannot store a secret has nowhere to put its credential">
    The Product's Dynamic Client Registration is issuing a confidential (secret-bearing) client, which a secret-less MCP client such as VS Code cannot use. Ask the Product's administrator to add or switch to a secret-less, PKCE-secured [Client Profile](/portal/api-products#configure-the-product-for-dcr) for Dynamic Client Registration, then request a new credential - an existing confidential credential does not convert automatically.
  </Accordion>
</AccordionGroup>