How Rocketlane shipped MCP auth in days, not quarters.
Rocketlane's MCP server ships 24 tools to Claude, Cursor, and ChatGPT. Scalekit handles the OAuth 2.1 layer in front of it, live in days, with the existing auth system untouched and EU customers covered from day one.
Rocketlane runs delivery and onboarding for professional services teams. A meaningful share of its customers are in the EU, so every new access surface has to clear the same residency bar as the core product.
Customers wanted to work from inside Claude and Cursor. Standing up compliant OAuth 2.1 for that, without touching the auth already running the app, was the hard part.
"OAuth 2.1, token refresh, per-tool scopes: solved, without touching our existing auth. Two days from wiring it up to Claude calling our MCP server in production."
MCP needed a second front door, without touching the first.
A standards-compliant OAuth 2.1 surface on top of the auth already running the app, without risking any of it.
Don't touch what's live
MCP auth had to sit alongside core auth. Zero risk to live sessions or SSO.
Days, not a quarter
Demand was already there. Every week building an OAuth 2.1 server was demand with nowhere to go.
US and EU, day one
Same residency bar as the rest of the product, not a follow-up project.
The AI client authenticates once. Rocketlane's auth never sees it.
Scalekit terminates the handshake and stores the token in a region-scoped vault. Rocketlane's own auth stays out of the path.
- 01OAuth 2.1 handshakeThe client authenticates against Scalekit.
- 02Token stored in-regionUS or EU vault, per the customer's residency.
- 03Validated tool callToken and per-tool scope checked, then forwarded.
- 04Internal call onlyExisting auth never sees an MCP client.
- OAuth 2.1 handshake
Claude, Cursor, or ChatGPT authenticates against Scalekit. No credentials reach Rocketlane.
- Token stored in-region
The token lands in a US or EU vault, matching the customer's residency requirement.
- Validated tool call
Scalekit checks the bearer token and per-tool scope, then forwards the call to Rocketlane's MCP server.
- Internal call only
The MCP server talks to Rocketlane's existing auth internally. That system never sees an MCP client.
"Our customers wanted to work inside Claude and Cursor, not just inside Rocketlane. Scalekit let us meet them there: live in days, EU residency built in, nothing rebuilt in our own auth stack."
For anyone standing up their own MCP server.
Three decisions that decide whether MCP auth takes a week or a quarter.
Treat MCP auth as its own layer
Bolting OAuth 2.1 onto an existing login system costs more than building it alongside.
Extend it, don't rebuild it
If your product already makes regional guarantees, MCP needs the same ones: routed, not re-engineered.
Budget for the unglamorous 80%
Tools are the interesting part. Refresh, revocation, and scopes across five clients is where weeks go.
What changes when auth isn't a build.
WITHOUT THIS PATTERN
- OAuth 2.1 server built and maintained in-house
- Existing auth system modified to accommodate MCP
- Separate residency logic for EU vs. US
- Manual token refresh and revocation handling
- Weeks of infra before the first tool call
ROCKETLANE + SCALEKIT
- Drop-in OAuth 2.1, spec-compliant from day one
- Existing auth system untouched
- One integration, region-aware token routing
- Refresh and revocation handled automatically
- Production in about two days
