MCP Server Authorization with OAuth 2.1 and Grantex

Short answer: for production, use an established, MCP-compatible authorization server for the HTTP OAuth flow. Then enforce agent-specific Grantex grants again at each sensitive tool or service boundary.

​

MCP authorization and Grantex solve different layers

1. Established authorization server: use a maintained authorization server that supports the current MCP profile, user authentication and consent, durable authorization-code state, secure client onboarding, token issuance, and revocation.
2. MCP protected resource: expose RFC 9728 protected-resource metadata, advertise the permitted authorization server, and validate every access token’s issuer, audience, expiry, and required MCP scopes.
3. Grantex tool enforcement: after transport authorization succeeds, use a primary Grantex SDK or direct, validated grant verification at each sensitive tool boundary. Bind the decision to the agent, principal, action, resource, constraints, and current revocation state.
4. Audit and deny safely: record both the transport authorization context and the tool-level Grantex decision. Deny the call if either layer fails.

​

What @grantex/mcp-auth 2.0.2 implements

​

Reproducible evaluation install

npm install --save-exact @grantex/mcp-auth@2.0.2 @grantex/sdk@0.3.13

npm ci

​

Start the evaluation endpoint surface

import { Grantex } from '@grantex/sdk';
import { createMcpAuthServer } from '@grantex/mcp-auth';

const grantex = new Grantex({
  baseUrl: 'https://api.grantex.dev',
  apiKey: process.env.GRANTEX_API_KEY!,
});

const authServer = await createMcpAuthServer({
  grantex,
  agentId: 'ag_your_mcp_server',
  scopes: ['tools:read', 'tools:execute'],
  issuer: 'https://your-auth-server.example.com',
});

await authServer.listen({ port: 3001 });

​

Six material limits in 2.0.2

1. Process-local state: client registrations use process memory unless you provide a ClientStore, and authorization codes always use the non-configurable InMemoryCodeStore. Restarts and multi-replica authorize/token flows are unsafe.
2. No consent page: consentUi adds discovery metadata only. The package does not register /consent or render a user-approval interface.
3. Incomplete code handoff: the package does not persist the authorization code returned by the Grantex SDK for the token handler. A real backend exchange can therefore fail.
4. Inactive issuance hook: the onTokenIssued type is declared but the hook is not invoked in 2.0.2.
5. No current revocation lookup: introspection and middleware perform local JWT validation but do not query current revocation state. Use an online state check or synchronized revocation data when immediate revocation matters.
6. No server-wide redirect allowlist: allowedRedirectUris is declared but is not enforced as a server-wide allowlist in this release. Authorization checks the redirect URI registered for the individual client instead.

​

Evaluation-only middleware boundary

import { requireMcpAuth } from '@grantex/mcp-auth/express';

app.use('/mcp', requireMcpAuth({
  issuer: 'https://your-auth-server.example.com',
  scopes: ['tools:execute'],
}));

​

Production checklist

• Follow the current MCP HTTP authorization specification rather than treating an older endpoint list as the protocol.
• Use an established authorization server and maintained MCP SDK, with exact versions pinned in your own lockfile.
• Publish and validate RFC 9728 protected-resource metadata for the actual MCP resource identifier.
• Validate issuer, audience, expiry, scopes, and revocation before accepting the transport token.
• Enforce the narrower Grantex grant at every sensitive tool or downstream service boundary.
• Test denial paths, consent, authorization-code replay, redirect URIs, multi-replica state, token expiry, and revocation end to end.

​

Related documentation

• MCP Auth Server package status
• Grantex release status
• MCP tool-server integration
• Self-hosting guide
• Current MCP HTTP authorization specification
• OAuth 2.1 Internet-Draft status