Protected resources
Register the MCP servers and APIs that Strivacity issues tokens for, and describe their scopes in language your customers understand.
A protected resource is a Model Context Protocol (MCP) server or API that Strivacity acts as the authorization server for. Registering a resource does two jobs at once: it tells Strivacity which resource URLs it may mint tokens for, and it gives your customers something recognizable (a name, a logo, and plain-language scope descriptions) when they're asked to consent.
Protected resources are accessed by OAuth2/OIDC clients. MCP servers are accessed by MCP clients (AI agents), while APIs can be accessed by agents or by any other OAuth2 client.
There are a few reasons every resource a client can reach should be registered:
- Strivacity refuses to issue tokens for resources / audiences it doesn't know about, which stops a client from requesting a token for an arbitrary audience.
- Access tokens are audience-restricted to the registered resource URL, so a token stolen from one resource can't be replayed against another.
- The authorization consent screens your customers see use the descriptions and logos you configure, so they understand what access they're granting.
Resource types
A protected resource has one of two types:
- MCP Server: an MCP server, per the Model Context Protocol specification.
- API: any other OAuth2-protected API.
The two types share the same configuration. The type determines where the resource appears in the Admin Console: MCP servers are also listed under Agentic AI > MCP servers, and are configured with settings that ensure MCP specification compliance.
Creating a protected resource
You can create a protected resource from two places in the Admin Console:
- Agentic AI > MCP servers > Create, which preselects the MCP server type.
- Policies > Protected resources > Create, where you choose the type yourself.
Both open the same form.
- Give the resource a Name and a Description. These identify the resource to brand admins; customers won't see them.
- Optional Assign a Policy tag to help organize your policies.
- Confirm the Type.
- Enter the Display name and Logo URL. This is what customers see on the consent screen and in the My Account portal, so use the name your customers know the service by.
- Enter the Resource URL: the canonical URL of the MCP server or API, for example
https://mcp.example.com/mcp. This is the value clients must send in theresourceparameter, and it becomes the audience of issued tokens. - Decide whether Consent required is on. When enabled, customers must approve the client's requested scopes on a consent screen during login before Strivacity issues a token for this resource.
- Add the resource's scopes (next section), and select Save.
Defining scopes
Each scope has two parts:
- Name: the technical scope value the client requests, for example
loyalty.balance.read. - Display name: the plain-language description shown to customers on the consent screen and in the My Account portal, for example "Read how many rewards points you have".
Write display names as things a customer would knowingly agree to. "Read how many rewards points you have" gets an informed yes or no. loyalty.balance.read doesn't.
Use Add scope to define each scope the resource supports. The scopes you define here are the catalog for the resource; which of them a given client may request, and how each is presented on the consent screen, is configured on the client. See AI agents. For dynamic clients, the same per-scope configuration lives on the dynamic client template instead. See Dynamic clients.
After saving, assign the resource to a client (such as an AI agent) and run a test authorization. The consent screen should show the display name, logo, and scope descriptions exactly as you entered them here.
Changing the resource URL later changes the audience of every token issued afterward, and clients configured with the old URL will fail RFC 8707 validation. Treat the resource URL as fixed once clients depend on it.
How resources are used at runtime
When a client requests authorization, it names the target resource in the resource parameter. Strivacity checks the value against the resource URLs of the protected resources or custom audiences assigned to that client, and rejects the request if there's no match. The issued access token's audience is the matched resource URL, and the MCP server or API must verify that audience before accepting the token.
Token format and access token lifespan are configured on the client, not on the resource. See AI agents for agent clients, or OAuth2/OIDC properties setup for generic clients.
Where to go next
- AI agents: assign resources to an agent client.
- Authorization consents: what customers see and how they manage what they've granted.
- Integrating an MCP server with Strivacity: what the resource's developer needs to build.
Updated 13 days ago

