Launching today
MCP-Billing
OAuth 2.1 + usage-based Stripe billing for MCP servers
25 followers
OAuth 2.1 + usage-based Stripe billing for MCP servers
25 followers
Self-hosted Next.js/TypeScript boilerplate: full OAuth 2.1 + PKCE, API key management with zero-downtime rotation, usage-based Stripe billing, and Redis rate limiting. 7 modules, 300+ tests. One-time €79, no revenue share, no platform lock-in. The metering core is free and open source on npm.
MCP-Billing
The OAuth half of this is the part I would pay for before the billing half. I connect MCP servers to my Claude setup as a user most weeks, and the pattern from that side is blunt, a server whose auth works on the first try gets used the same day, and one that fails sits unauthenticated for weeks. I have one in that exact state right now. Does your OAuth 2.1 flow cover the interactive consent dance the desktop AI clients run, or is it aimed at headless API consumers with keys?
MCP-Billing
@abdullah_javaid3
it covers the real interactive consent flow, not an auto-approve shortcut. when a client kicks off the OAuth 2.1 PKCE authorization code grant, the user lands on an actual consent page in the dashboard to review requested scopes and click "Allow" or "Deny" (backed by TOCTOU protection in the server action and explicit tests for both decisions). so it's definitely built for interactive consent rather than just headless API keys.
that said, to be 100% transparent about a current gap that might affect your exact setup: right now the redirect_uri validation relies on a web-app whitelist checking for https:// or standard http://localhost:port/. if the desktop client you're using relies on RFC 8252 native app patterns like loopbacks with dynamic ports or custom schemes (like claude://), my current validation regex won't cover it — it's a narrow whitelist, easy to extend but not built in yet.
i also haven't tested it end-to-end against a live Claude Desktop client instance yet—the test suite exercises the server actions and handlers directly with mock clients.
curious though, what's the auth setup or custom scheme on the server sitting unauthenticated in your setup right now? would love to know if it's hitting that exact loopback/scheme restriction so i can prioritize it.
@marc_gil1 Honest answer, the stalled one is a hosted server that authenticates through the Claude client itself, browser consent and then a redirect back to a localhost callback the client spins up on a random port. So it is exactly your RFC 8252 case, loopback with a dynamic port, and a fixed localhost whitelist would refuse it. The stall on my side was friction rather than rejection, the flow needs the human at the keyboard at the right moment and that moment kept losing. If desktop AI clients are buyers you care about, the dynamic port loopback looks like the piece to prioritize, and a live end to end run against a real Claude client would tell you more than the mock suite there.
MCP-Billing
@abdullah_javaid3 that's brilliant context, thanks a lot for confirming.
on the loopback validation: you're 100% right. expanding the redirect_uri check to validate standard RFC 8252 dynamic ports instead of exact string matching is a surgical fix (adjusting the URI regex / port validator), and i'm adding that directly to the top of the OAuth backlog.
on the friction point: to be totally clear on how it behaves right now, the consent screen itself actually doesn't time out while sitting open. the request parameters live in the form inputs, and clicking "Allow" re-validates them fresh against Postgres with TOCTOU protection. the 60-second TTL only starts after you click "Allow", which is when the single-use authorization code gets issued for the client to exchange.
so while a timeout isn't kicking the user off the page, you nailed the real UX gap: there's zero client-server orchestration built for when the human isn't sitting at the keyboard at that exact moment. no push notification, no deep-linking polling to wake up the client, nothing. the boilerplate handles the auth primitives, but not the "notify the user when it's time to approve" UX.
and you're completely right about the end-to-end testing against a real Claude Desktop instance. headless mock suites verify the protocol specs, but they completely miss this kind of real-world human-in-the-loop friction. really appreciate you breaking this down!