Launching today
NitroStack
Build, test, and deploy MCP servers in one place
355 followers
Build, test, and deploy MCP servers in one place
355 followers
NitroStack is the full-stack platform for building production-ready MCP servers and AI apps. Build with open-source TypeScript & Python SDKs, test and debug visually in NitroStack Studio, orchestrate agent workflows with NitroStack Workflow, deploy on NitroStack Cloud, and ship branded experiences with NitroStack Chat. Auth, testing, deployment and frontend stay in one workflow. Connect to ChatGPT, Claude and other AI clients. Powering 80,000+ MCP servers.
Free Options
Launch Team
Dropbox SignSimple, secure eSignatures for the way your team works.
Promoted
Congrats Abhishek and the NitroStack team on the launch. Going from a decorated Zod tool to a deployed server on NitroCloud in one flow is the part that would save me the most glue code. To answer your question, what I still stitch together myself is per-user OAuth when a tool calls a downstream API like Google or Salesforce on behalf of the end user. Do the SDK auth modules store and refresh those tokens per user, or is that still on me?
@genedai Thank you, Gene. We appreciate the kind words.
To answer your question: NitroStack validates the OAuth 2.1 token on every tool call, so each tool knows which user is calling. The server is stateless and does not need sessions to do this. For downstream services such as Google and Salesforce, the SDK includes an OAuth 2.1 client that handles PKCE authorization, token exchange, refresh, and revocation.
Storing those downstream tokens for each user is currently up to you as the developer. There are two common approaches. You can let your identity provider hold the tokens (Auth0 Token Vault is one example) and exchange the verified user identity for a fresh token at call time. Or you can implement the SDK's TokenStore interface on top of your own database, keyed by user. A built-in helper that handles the whole flow in a single call is on our roadmap.