Integrating an MCP server with Strivacity

This page is for the developer building or operating a Model Context Protocol (MCP) server (or agent) that uses Strivacity as its authorization server. It covers what Strivacity provides, what your MCP server must implement per the MCP specification, and how tokens are validated.

Strivacity implements the authorization portions of the MCP specification. Your MCP server acts as an OAuth 2.1 resource server; the agent is the OAuth client; Strivacity authenticates the customer, gathers consent, and issues tokens.

Before you begin

Ask your brand admin for:

• The MCP server registered as a protected resource, with its canonical resource URL and scopes. See Protected resources.
• Your instance's issuer URL: https://BRAND_DOMAIN.strivacity.com.
• An agent to test with: either an AI agent client registered with your resource assigned, or dynamic client support enabled so your test agent can identify itself. See AI agents and Dynamic clients.

Authorization server discovery

Strivacity publishes authorization server metadata through OIDC Discovery:

https://BRAND_DOMAIN.strivacity.com/.well-known/openid-configuration

The RFC 8414 oauth-authorization-server well-known path isn't published. That's fine for spec compliance: the MCP specification requires clients to support both discovery mechanisms, so a conforming client tries the RFC 8414 path, gets no document, and falls back to OIDC Discovery. The metadata includes code_challenge_methods_supported, which MCP clients require before proceeding, since PKCE is mandatory.

With Client ID Metadata Documents enabled, the discovery metadata additionally advertises client_id_metadata_document_supported: true, which is how MCP clients learn they can self-identify.

Your MCP server is responsible for the other half of discovery: the MCP specification requires resource servers to publish OAuth 2.0 Protected Resource Metadata (RFC 9728) naming Strivacity as their authorization server. Serve a metadata document whose authorization_servers array contains your issuer URL, and advertise it on 401 responses:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource/mcp",
                         scope="loyalty.balance.read"

Including a scope parameter is recommended: it tells the agent the minimum scopes to request, so the first consent screen your customers see isn't asking for everything.

The resource parameter

Agents must include the resource parameter (RFC 8707) in both the authorization request and the token request, set to the canonical URL of your MCP server exactly as registered in Strivacity:

&resource=https%3A%2F%2Fmcp.example.com%2Fmcp

Strivacity matches the value exactly against the resource URLs of the protected resources assigned to the agent's client, and rejects requests naming anything else. The matched resource URL becomes the audience of the issued access token.

Validating tokens

Your MCP server must validate every request's bearer token:

• Verify the signature against Strivacity's JSON Web Key Set (JWKS), published in the discovery metadata. Ask your admin to set the agent client's access token format to JWT so you can validate locally.
• Verify the audience claim is your resource URL. Reject tokens issued for any other resource; this is what prevents a stolen token from being replayed against your server.
• Reject expired tokens with HTTP 401.

Step-up authorization with scope challenges

When an agent calls your MCP server with a valid token that lacks a required scope, respond with a scope challenge per the MCP specification:

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope",
                         scope="loyalty.balance.read loyalty.transfer.standard",
                         resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource/mcp"

Include every scope needed to satisfy the request in the scope parameter, not just the missing one, so the agent doesn't lose previously granted access when it re-authorizes.

The agent then re-runs the authorization flow with the challenged scope set. Strivacity walks the customer through authentication (subject to session policy) and shows an authorization consent screen for the additional access. On approval, the agent receives a new token carrying the expanded scopes and retries the request.

This is the mechanism to use for attended, transaction-style escalation: keep your baseline scopes minimal, and challenge for sensitive operations when the customer is present to approve them.

Auditing

Actions an agent performs appear in the customer's account events with the account as the subject and the agent's client as the actor, in both the Admin Console and the API.

Where to go next

• Protected resources and AI agents: the admin-side registration.
• OIDC support: Strivacity's OAuth2/OIDC flows and well-known URLs.