How MCP Auth Coexists with Your Existing Identity Stack

Developer

No items found.

Modern B2B apps often need to work across multiple systems, identities, and contexts especially when serving enterprise customers with their own SSO or federated login setup. Scalekit’s MCP Auth layer lets you bring your own authentication system while layering on a compliant, OAuth 2.1-ready authorization flow — no rip-and-replace needed.

Let’s break down how it fits alongside your existing identity setup.

1. The Big Idea: Federated, Not Replaced

Scalekit’s MCP Auth doesn’t force you to abandon your login flow. Instead, it wraps your existing auth (OIDC, SSO, or even username-password) inside a standards-compliant OAuth 2.1 layer.

When an MCP client initiates a login, Scalekit redirects to your existing login endpoint. Once you authenticate the user, you simply hand the verified user info back to Scalekit. That’s it — the rest (state management, consent, tokens) is handled automatically.

This makes it ideal for teams running internal identity providers, B2B auth brokers, or custom login experiences who want Scalekit’s interoperability and compliance without disrupting their flows.

2. How It Works (End-to-End)

Here’s the flow in practice:

Step 1: Initiate Authentication

An MCP client begins the OAuth 2.1 flow by calling /oauth/authorize.

Scalekit then redirects the user to your login page, along with:

login_request_id — a unique identifier for the auth request
state — a random value to prevent CSRF and track the flow

Example redirect:

https://app.example.com/login?login_request_id=lri_86659065219908156&state=HntJ_ENB6y161i9_P1yzuZVv2SSTfD3aZH-Tej0_Y33_Fk8Z3g

Step 2: Handle Authentication on Your End

This is your normal login flow — password, SSO, magic link, anything.
Once the user is verified, you make a machine-to-machine POST back to Scalekit, sending the user profile attributes.

Example:

curl --location '{{envurl}}/api/v1/connections/{{connection_id}}/auth-requests/{{login_request_id}}/user' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer {{access_token}}' \ --data-raw '{ "sub": "1234567890", "email": "alice@example.com", "given_name": "Alice", "family_name": "Doe", "email_verified": true, "phone_number": "+1234567890", "phone_number_verified": false, "name": "Alice Doe", "preferred_username": "alice.d", "picture": "https://example.com/avatar.jpg", "gender": "female", "locale": "en-US" }' }

Scalekit uses this to map and complete the federated user context.

Watch the Walkthrough

If you prefer a hands-on guide, check out this short video walkthrough of the full flow — how MCP Auth protects your app.

Step 3: Redirect Back

Once Scalekit confirms receipt, redirect the user back to:
‍

{{envurl}}/sso/v1/connections/{{connection_id}}/partner:callback?state={{state_value}}

Step 4: Done — Scalekit Takes Over

At this point, Scalekit handles the rest:

Consent screen (if applicable)
Token issuance (OAuth 2.1)
Secure session handoff

Your backend can remain lightweight, only focusing on verifying users and sending data securely.

3. Why This Approach Works

✅ No need to rewrite login flows — keep your existing auth logic.
✅ Layered security — Scalekit manages token lifecycle and compliance.
✅ Faster integration — minimal backend updates, no custom OIDC providers required.
✅ Future-ready — enables smooth interoperability across MCP clients and partner systems.

You can think of it as OAuth2.1 wrapping for your existing identity system.

4. Next Steps

To test it locally, check out our Sample MCP Server on GitHub — a full working implementation that includes both authentication and authorization examples.

On this page

Toc link here

Share this article