Model Context Protocol servers connect AI applications to tools and data. When those tools require user or enterprise access, OAuth and related identity controls become a critical security boundary. A successful login is not enough: tokens must be issued to the right client, constrained to the right server and authorised for the exact resource and action.
MCP authorization testing evaluates discovery, client registration, consent, token handling, scope enforcement and the tool gateway behind the protocol. It should combine standards-based OAuth checks with application-specific tests for agent identity, user delegation and business logic.
What this security assessment should prove
The assessment should prove that an MCP client cannot obtain, replay or redirect authority beyond the initiating user’s intent. Resource servers must validate issuer, audience, expiry and permission, while every tool call receives its own deterministic authorisation decision.
A useful test does not stop when a model produces an unusual sentence. It follows the workflow to the server-side decision, data access or tool result. The finding should explain who can trigger the behaviour, what trust boundary fails and what business outcome becomes possible.
Map the attack surface before testing
Record the model and version, system instructions, users, identities, data sources, tools, APIs, approval steps, memory and downstream systems. Mark which inputs are trusted, which can be influenced by an attacker and where deterministic policy is expected to make the final decision.
1. Incorrect authorization-server discovery
A client may follow manipulated metadata or mix issuers. Test protected-resource metadata, redirects, TLS validation and strict issuer matching.
2. Token audience confusion
A token created for one server may be accepted by another. Present tokens across environments and services and verify audience and resource validation.
3. Overbroad scopes
Generic scopes can grant every tool or data source. Compare requested access with the selected workflow and test whether unused privileges are rejected.
4. Consent and approval confusion
A user may see an incomplete or misleading approval screen. Verify client identity, destination, resources, actions and duration are understandable and bound to the transaction.
5. Client and redirect attacks
Test redirect URI validation, state and PKCE, dynamic registration policy and whether malicious clients can impersonate trusted software.
6. Token leakage and replay
Inspect browser storage, logs, traces, referrers, error messages and tool output. Replay tokens after logout, revocation and role change.
7. Confused-deputy tool calls
A valid agent may use its token for an object or function the user cannot access. Test resource ownership at the API behind each tool.
A practical testing methodology
Use written authorisation, test identities and synthetic sensitive data. Prefer a representative staging environment; if production testing is necessary, agree on safe actions, rate limits, emergency contacts and stop conditions. Record the exact model, configuration and timestamp because probabilistic behaviour can change between runs.
Step 1: Inventory actors and flows
Document MCP clients, servers, authorization servers, redirect URIs, grant types, scopes, audiences and resource APIs. Separate local and remote trust assumptions.
Step 2: Validate discovery and issuer binding
Change metadata locations, issuer values and authorization responses. Clients should reject mismatches and insecure redirects.
Step 3: Test authorization-code protection
Verify exact redirect matching, state, PKCE and one-time code use. Attempt code interception and replay with a different client.
Step 4: Test tokens at every boundary
Change audience, issuer, expiry and scope; use a token from another environment; and verify revocation. Avoid decoding a JWT without validating it.
Step 5: Exercise tool-level authorisation
Use two users, roles and tenants. Change resource identifiers and call tools directly. The backend must enforce ownership and function permissions.
Step 6: Review consent and elicitation
Confirm that the interface never asks users to paste passwords or secrets into prompts and that approvals identify the real action and recipient.
Step 7: Validate logs and containment
Trace user, client, agent, token subject, tool, resource and outcome. Confirm that one compromised client or token can be revoked without disabling unrelated integrations.
Controls to verify
- Standards-compliant authorization-code flow with PKCE and strict redirect validation.
- Exact issuer and audience validation at clients and resource servers.
- Short-lived tokens, secure storage, rotation and effective revocation.
- Granular scopes plus object- and function-level server-side authorisation.
- Clear consent bound to client, resource, action and duration.
- No credentials or bearer tokens in prompts, logs or tool results.
- Distinct identities for users, agents, clients and servers with complete audit context.
Do not treat a system prompt or a refusal message as an access-control boundary. High-impact actions need deterministic validation, least-privilege credentials and reliable audit records outside the model.
Evidence, severity and retesting
For every confirmed issue, capture prerequisites, identities, input source, prompts or files, relevant requests, tool calls, policy decisions and final outcome. Use the minimum-impact proof necessary. Severity should reflect demonstrated confidentiality, integrity, availability or financial impact—not how surprising the model response appears.
After remediation, repeat the exact case and nearby variants. Add successful tests to a regression suite that runs after changes to models, prompts, tools, permissions and data sources. Track coverage and unresolved high-risk outcomes rather than counting only blocked prompts.
How this fits into a broader AI assessment
Start with how to secure MCP servers and AI tool integrations. Pair protocol testing with API penetration testing and the non-human identity security guide.
Frequently asked questions
Does MCP require OAuth for every deployment?
No. Transport and deployment models vary, but remote access to protected resources needs an appropriate authentication and authorization design.
Is scope validation sufficient?
No. Scopes describe broad permission; APIs must still enforce role, tenant, object ownership and business rules.
Should an agent receive a user’s full token?
Prefer delegated, audience-restricted and narrowly scoped authority rather than reusable broad credentials.
Conclusion
MCP security depends on correct identity and authorization beyond the protocol message. Bind tokens to the intended server, reduce delegated authority and enforce every business action at the resource API.
OAuth test cases for an MCP deployment
Cross-resource token reuse
Obtain a legitimate token for one MCP server and present it to another server in the same organisation. Repeat across development and production. Acceptance indicates missing audience or resource validation and can turn one compromised integration into broader access.
Authorization response mix-up
Use two authorization servers or tenants and attempt to complete a flow with a response from the wrong issuer. The client should validate issuer information and bind the response to the initiated transaction.
Redirect and client impersonation
Register or simulate a lookalike client and vary redirect URIs, schemes, ports and path encodings. Exact validation, PKCE and state should prevent an attacker from receiving an authorization code intended for a trusted client.
Scope-to-tool mismatch
Request a broad scope, then call sensitive tools that were not necessary for the user’s selected task. The server should enforce tool- and resource-level policy rather than interpreting a generic scope as unrestricted permission.
Revocation and queued work
Revoke access while the agent has pending tasks. Confirm that execution re-checks token validity and user authority instead of relying on a decision made when the queue item was created.
Common MCP authorization mistakes
- Accepting any correctly signed token without checking issuer and audience.
- Using one scope for every tool and dataset.
- Putting bearer tokens into prompts, model context or debug logs.
- Trusting the client to enforce tenant and object ownership.
- Allowing redirect wildcards or weak dynamic registration policy.
- Showing consent without the real server, resource and action.
- Keeping long-lived tokens active after user or role changes.
Evidence and remediation ownership
Capture discovery metadata, client identity, authorization request, response parameters, token claims, resource decision, tool arguments and final API result. Assign fixes to the correct layer: client, authorization server, MCP server, tool gateway or business API. A gateway patch is incomplete if the underlying API remains callable with excessive authority.
Production-readiness checklist
- Issuer, audience, expiry and signature are validated everywhere.
- Redirects are exact and authorization code flows use PKCE and state.
- Scopes are narrow and resource ownership is enforced separately.
- Tokens never enter prompts or unredacted telemetry.
- Consent names the client, server, action and duration.
- Revocation stops queued and direct actions promptly.
- Logs link the human, agent, client, tool and resource outcome.
Testing frequency and ownership
Repeat MCP authorization tests after changes to clients, servers, discovery metadata, redirect URIs, scopes, authorization servers or protected APIs. Identity teams own token issuance and lifecycle; MCP server owners enforce protocol handling; application teams enforce object and business permissions. Security testing should connect these layers. A token that is valid cryptographically can still be invalid for the requested user, resource or action.
Questions for architecture review
Ask which component is the OAuth client, which server owns the protected resource and where the final policy decision is made. Confirm how local clients differ from remote clients, how redirect URIs are registered and how users revoke access. Review whether tokens are sender-constrained or usable by anyone who obtains them, and whether service-to-service calls preserve the initiating user’s context.
Finally, test the operational lifecycle: onboarding a server, rotating keys, changing scopes, removing a client and investigating a suspected leak. Secure protocol design must remain manageable during routine change and incident response.
