What’s a resource server?
In the protocol, the MCP server you register is the resource server — the system C1 issues tokens for. You register one per server, keyed to that server’s authorization server. The token C1 mints is addressed to that authorization server, which verifies C1’s signature and exchanges the token for an access token the agent uses to call the server.Before you begin
- The application for this server already exists in C1.
- The MCP server’s authorization server already trusts C1 as an issuer. The server’s owner does this, not you, and not in C1. See Support enterprise-managed authorization in your MCP server.
Register an MCP server
The MCP server is registered on the C1 application that represents it. The Cross-App Access tab only appears once enterprise-managed authorization is enabled for your tenant.Click Register resource server.This opens the Register resource server drawer. There is no per-application enable toggle — enablement is the tenant-level setting on the Enable enterprise-managed authorization page.
Set the Audience (required).The audience is the issuer URL of the MCP server’s authorization server. It is fixed once the resource server is created, so set it correctly the first time. The audience must not be your own C1 tenant URL. C1 is the token issuer, not the audience.
Add the Resource URIs.These are the MCP server URLs the agent will call. Type each URI and press Enter to add it. A token request that names a target outside the configured resource URIs is denied.
Optional. Set a Maximum grant lifetime and a Signing algorithm.Maximum grant lifetime is a duration picker — leave it on Indefinite to inherit the tenant default (which resolves to 300 seconds / 5 minutes if the tenant hasn’t set one). Indefinite means “inherit the tenant default,” not “tokens never expire.” Signing algorithm defaults to Inherit (default) (your tenant’s default); the other options are EdDSA, RS256, and ES256. Change it only if this server’s authorization server verifies a different algorithm. The algorithm you pick must be maintained at the tenant (have a signing key), or every token request for this server is denied.
Modify-claims hook (not yet available)
The resource server drawer shows a Modify-claims hook field, intended for attaching a Function that would run when C1 mints a token for this server. This capability is not yet functional — the field is reserved for a future release.Pause an MCP server
To pause a server, disable its resource server. In the UI this is the Disable action — use the ⋯ menu on the resource server’s row (or on its detail page), or toggle Disabled (kill switch) in the resource server drawer. Re-enabling is the Enable action in the same menu. Disabling a resource server is a per-server off switch. It denies new token requests for that server without deleting its configuration. The audience, resource URIs, signing algorithm, and scope setup are kept, so re-enabling restores the server as it was. Disabling a server does not stop a token that has already been minted. An issued token keeps working until it expires, which is a few minutes by default. It affects the next token request, not tokens already in use.Troubleshoot resource server errors
If a token request is denied, or a server rejects a token C1 issued, find your issue below.The audience isn't registered
The audience isn't registered
The token’s audience does not match a registered resource server. Confirm the resource server’s audience is the issuer URL of the MCP server’s authorization server, and that it matches what the agent’s client is asking for. The audience is fixed after creation, so a mismatch means re-registering the server with the correct audience.
A call's target URL isn't in the resource URLs
A call's target URL isn't in the resource URLs
The token request names a target that isn’t in the resource server’s configured resource URLs, so C1 denies it. Add the URL the agent is calling to the resource URLs for this server.
The server rejects a token because of a signature-algorithm mismatch
The server rejects a token because of a signature-algorithm mismatch
C1 minted the token, but the server’s authorization server rejected its signature. The server verifies a different algorithm than the one this resource server is signing with. Set this server’s signing algorithm to one its authorization server verifies. ES256 is the broadest choice.
Where to go from here
- Enable and govern this server’s scopes. See Govern access: scopes & access profiles.
- Set up the server to accept C1 tokens. See Support enterprise-managed authorization in your MCP server.
- Want the full picture? See the enterprise-managed authorization overview.