Oct 10, 2025

How MCP auth coexists with your existing identity stack

Developer

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.

Step 3: Redirect the user

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.

FAQs

How does MCP Auth integrate with my current identity stack?

Scalekit's MCP Auth utilizes a federated approach rather than a rip and replace strategy. It wraps your current identity provider, whether it is OIDC, SAML, or custom username password setups, within a standards compliant OAuth 2.1 layer. This ensures that your existing authentication logic remains intact while Scalekit manages the complex aspects of interoperability and authorization. By acting as a thin wrapper, it bridges the gap between your internal identity systems and the modern requirements of MCP clients, allowing for seamless integration without forcing architectural overhauls or disrupting the current user experience.

What are the security benefits of using OAuth 2.1 federation?

Layering OAuth 2.1 federation provides several architectural security advantages, particularly for enterprise B2B applications. Scalekit handles critical security functions such as state management, CSRF protection, and secure token issuance. By delegating these responsibilities to a compliant layer, you minimize the risk of implementation errors in your own backend. Furthermore, Scalekit manages the consent screens and secure session handoffs, ensuring that sensitive user data is handled according to modern security protocols. This approach allows CISOs to maintain high security standards while enabling developers to focus on core business logic without worrying about the intricacies of the OAuth specification.

Do I need to replace my existing SSO login flows?

No, there is absolutely no need to abandon or replace your existing SSO or login flows. Scalekit is designed to coexist with your current identity infrastructure by acting as an orchestration layer. When a client initiates a login request, Scalekit redirects the user to your established login page. Your system performs the actual authentication as it always has, and then simply communicates the verified user attributes back to Scalekit via a secure machine to machine API call. This ensures a friction free transition for your users while providing you with a standardized authorization output for all your connected services and agents.

How is the user context handled during the authentication process?

During the flow, user context is managed through a secure handoff mechanism between your application and Scalekit. Once your system verifies the user identity, you send a POST request to Scalekit containing profile attributes such as the unique identifier, email, and name. Scalekit uses this information to map and complete a federated user context within the OAuth 2.1 session. This process ensures that the resulting tokens contain the necessary claims and identity data required by downstream services, allowing for consistent identity propagation across various agents and platforms without complex manual session synchronization or database lookups.

Can MCP Auth support machine to machine and agent communication?

Yes, the MCP Auth architecture is specifically built to facilitate secure machine to machine and agent to agent communication. By standardizing on OAuth 2.1, Scalekit allows AI agents and automated services to interact using robust token based authorization. This is particularly useful in B2B environments where applications must work across multiple systems and contexts. The platform handles the underlying complexities of token exchange and validation, making it easier for engineering teams to build interoperable agents that can securely access protected resources. This setup ensures that every automated interaction is properly authenticated and authorized according to the specific context of the enterprise environment.

What role does Scalekit play in managing token lifecycles?

Scalekit takes full responsibility for the lifecycle management of OAuth 2.1 tokens, which significantly reduces the operational burden on your engineering team. This includes the generation, signing, and secure distribution of access and refresh tokens. Scalekit also handles the validation of these tokens during subsequent API requests, ensuring that only authorized clients can access protected resources. By centralizing token management, you ensure consistent security policies across your entire application ecosystem. This approach also simplifies the implementation of token revocation and rotation strategies, which are essential for maintaining a high security posture in modern enterprise identity architectures.

Is it necessary to build a custom OIDC provider?

Building a custom OIDC provider is a complex and error prone task that can take months of development time. Scalekit eliminates this necessity by providing a turnkey solution that layers on top of your existing identity stack. You get all the benefits of a standards compliant OIDC and OAuth 2.1 implementation without the high cost and maintenance overhead. This allows your team to achieve faster time to market while ensuring that your application remains future ready and interoperable with other MCP clients. Scalekit handles the heavy lifting of compliance and protocol adherence, letting you focus on delivering value to your enterprise customers.

How does this architecture simplify compliance for enterprise B2B apps?

Scalekit simplifies compliance by providing a standardized, auditable layer for all authorization activities. Since it follows the latest OAuth 2.1 specifications, it automatically adheres to modern security and privacy requirements expected by enterprise CISOs. The platform provides detailed logging and state management, making it easier to demonstrate compliance during security audits. Additionally, because you keep your existing authentication logic, you maintain control over data residency and identity verification processes. This hybrid approach ensures that you can meet stringent enterprise requirements for data protection and access control while benefiting from a modern, scalable authorization framework that grows with your business needs.

What steps are required to initiate the MCP authentication flow?

The flow begins when an MCP client calls the authorize endpoint, triggering a redirect to your login page with a unique login request ID. Your application handles user authentication through your preferred method, such as SSO or magic links. After successful verification, your backend makes a secure machine to machine API call to Scalekit to provide the user profile data. Finally, you redirect the user back to the Scalekit callback URL. From there, Scalekit manages the consent screen and issues the final OAuth 2.1 tokens, completing the secure handoff and enabling the client to access the requested resources or services.

No items found.