The package registers OAuth discovery, dynamic client registration, authorization, token, introspection, and revocation endpoint surfaces, plus JWT middleware. Version 2.0.2 has material state, consent, code-handoff, hook, and live-revocation limitations and is not a production-ready authorization server.
npm install @grantex/mcp-auth@2.0.2 @grantex/sdk@0.3.13
Copy
These are implementation limits in the published npm artifact, not optional production configuration. Evaluate the endpoint and middleware shape, but do not rely on this release for end-to-end authorization issuance or horizontally scaled state.
Authorization codes always use a non-configurable in-memory store. They are not shared across processes or durable across restarts.
The consentUi option contributes discovery metadata only; the package does not register or render a consent route.
The Grantex authorization code is not persisted for the token handler, so the end-to-end authorization-code exchange can fail.
Middleware and introspection validate JWT signatures and claims but do not query current Grantex revocation state.
onTokenIssued is declared in the API but is not called by the 2.0.2 token path. Host applications cannot treat it as an audit hook.
Client registrations default to process memory. A custom ClientStore can persist registrations, but it does not replace the process-local authorization-code store.
Canonical details: MCP Auth feature status · Grantex release status
The package is useful for inspecting endpoint registration, PKCE validation, client registration, JWT claim checks, and scope middleware. The limitations below prevent a production-readiness or full MCP authorization claim.
| Area | Implemented in 2.0.2 | Current boundary |
|---|---|---|
| Authorization endpoint | Request and PKCE validation | No consent page; Grantex code is not handed durably to the token path |
| Scoped middleware | ✓ JWT signature, claims, and required scopes | No current-revocation lookup |
| Revocation route | Forwards a revocation request | Subsequent middleware and introspection remain local checks |
| Audit integration | Host can add its own logging | onTokenIssued is not invoked; no full audit trail is supplied |
| Dynamic client registration | ✓ Pluggable ClientStore |
Authorization codes remain process-local even with a durable client store |
| Local JWT signature and claim validation; no live revocation query | ✓ JWT signature and claim validation | No online grant or revocation-state query |
| Deployment status | Single-process evaluation | No production, horizontal-scale, or full conformance claim |
createMcpAuthServer() registers
the documented discovery and OAuth route surface for controlled evaluation. Route presence does not imply complete end-to-end issuance or conformance.
| Method | Endpoint | RFC | Description |
|---|---|---|---|
| GET | /.well-known/oauth-authorization-server | RFC 8414 | Server metadata discovery |
| POST | /register | RFC 7591 | Dynamic Client Registration |
| GET | /authorize | OAuth 2.1 draft profile | PKCE-validated authorization request; no rendered consent route |
| POST | /token | OAuth 2.1 draft profile | Code and refresh handlers; authorization-code handoff is incomplete |
| POST | /introspect | RFC 7662 | Local JWT signature and claim validation; no live revocation query |
| POST | /revoke | RFC 7009 | Forwards a revocation request; local middleware state is unchanged |
Pin the published packages, run one local process, and inspect the registered routes and middleware. This setup does not repair the consent, code-handoff, hook, or live-revocation gaps.
Install the exact evaluation release with its Grantex SDK dependency.
npm install @grantex/mcp-auth@2.0.2 @grantex/sdk@0.3.13
Define evaluation scopes and an issuer. The package registers the route surface and performs selected PKCE, client, JWT, and scope checks; review the limitations above before exercising token flow.
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', 'resources:read'], issuer: 'https://mcp.yourcompany.com', }); await authServer.listen({ port: 3001 });
The Express or Hono middleware validates JWT signatures and claims against JWKS and enforces required scopes. It does not query current revocation state; add an online or synchronized revocation check before protected production actions.
import express from 'express'; import { requireMcpAuth } from '@grantex/mcp-auth/express'; const app = express(); // Protect all MCP tool routes app.use('/mcp', requireMcpAuth({ issuer: 'https://mcp.yourcompany.com', scopes: ['tools:execute'], })); // Decoded grant available on every request app.post('/mcp/tools/call', (req, res) => { const grant = req.mcpGrant; console.log(grant.agentDid, grant.scopes); res.json({ result: 'tool executed' }); });
Registered MCP servers can submit a Bronze, Silver, or Gold certification application and track its pending status. Automated conformance decisions, badge delivery, placement guarantees, and audience-reach claims are not currently implemented.
Changing the Grantex SDK base URL selects the Grantex backend used by the package. It does not make MCP authorization-code state durable, add a consent page, repair the code handoff, invoke the token hook, or add live revocation checks.
Use https://api.grantex.dev for the Grantex API calls made by the package. The MCP wrapper itself still runs in your single Node.js process.
Point the SDK at your own Grantex service when evaluating the same route surface against self-hosted infrastructure.
A durable ClientStore can persist registrations only. Authorization codes remain in the package's process-local map.
Do not put multiple package processes behind a load balancer or expect pending authorization codes to survive a restart.
Run one process, use non-production clients and principals, inspect the registered metadata and routes, test middleware signature/scope rejection, and plan separate consent, durable state, revocation-state, and audit integrations before production design.
These checks are useful evaluation inputs. They do not, by themselves, establish production readiness, complete OAuth or MCP conformance, live revocation, or an audit trail.
The authorization route requires an S256 challenge and rejects the plain method.
Middleware verifies supported asymmetric JWT algorithms against configured JWKS and rejects HS256.
Codes in the local store are removed when consumed, but they are not durable or shared and the Grantex code handoff remains incomplete.
The published package applies fixed limits of 10/min on authorize and 20/min on token and introspection routes.
Add explicit host logging for authorization, introspection, and revocation. Do not rely on onTokenIssued; it is not invoked in 2.0.2.
Default client secrets and local authorization codes use Node.js cryptographic random bytes.
Use the pinned 2.0.2 package in one controlled process to inspect its routes and middleware. Review the state, consent, code-handoff, hook, and revocation-check limitations before designing a production authorization service.
npm install @grantex/mcp-auth@2.0.2 @grantex/sdk@0.3.13
Copy