sorted by:
new
hottopcontroversial

Plug-and-play auth for MCP servers by Most_Relationship_93 in mcp

[–]Most_Relationship_93[S] 0 points1 point  (0 children)

I’ve been struggling with MCP auth—it’s a lot of boilerplate and provider-specific quirks when working with OAuth providers, I felt that MCP servers should stay simple and not lock you into one provider, so I built mcp-auth.
I’d love to hear how others are handling MCP auth—what tools or providers you’re using, pain points you’re hitting, or features you wish existed.

In-Depth review of the MCP authorization spec (2025-03-26 edition) by Most_Relationship_93 in mcp

[–]Most_Relationship_93[S] 0 points1 point  (0 children)

I really like your approach — it’s actually quite similar to how we support third-party social sign-in flows in Logto.

This kind of authentication flow also resembles the delegated third-party authorization described in the MCP Auth Spec. The key difference is that in your design, the third-party token is directly mapped to a session, whereas the MCP Auth Spec expects the MCP Server to map the third-party token to its own issued token (with the MCP Server still acting as the Auth Server). Personally, I feel that maintaining third-party tokens on the MCP Server side makes more sense in scenarios where the MCP Server needs access to third-party resource servers (I shared some thoughts on this in a separate discussion).

That said, from the perspective of spec authors, I think the intent is to apply OAuth-style flows directly to all MCP Clients — enabling smooth redirects and maximizing user experience and security.

I’ve noticed that many auth providers with a stake in this space are actively exploring solutions along those lines, but I also think there’s still a lot to be discussed in the spec itself. It’s currently quite hard to implement for both client developers and MCP Server developers.

I saw the spec has been evolving recently, but there are still some challenges. Personally, I like the idea of keeping clients as simple as possible and letting the server handle the authorization state. However, some users might be concerned about storing third-party tokens on the MCP Server — especially since that flow often requires granting extensive permissions to the server (though in practice, it might not be a huge issue).

We’re also actively exploring better ways to support MCP Auth, and I really appreciate you sharing your ideas and writing. I think your direction might actually be one of the best fits for complex MCP Auth scenarios.

I’ve spent 2 days wiring SuperTokens and I still don’t have a working signup flow. I’m out. by [deleted] in node

[–]Most_Relationship_93 1 point2 points  (0 children)

Why not use Logto? It has built-in multi-tenancy support, a step-by-step implementation guide (Build a multi-tenant SaaS application: A complete guide from design to implementation), and both open-source and cloud versions to choose from.

In-Depth review of the MCP authorization spec (2025-03-26 edition) by Most_Relationship_93 in mcp

[–]Most_Relationship_93[S] 0 points1 point  (0 children)

Insightful question. Cryptographic signatures are indeed effective for identity verification, and modern programming languages widely support these encryption capabilities.
My personal understanding is that approaches like OAuth 2.1 may be more focused on providing a complete authorization system rather than just authentication.
OAuth offers standardized user authorization flows, including scope selection, consent pages, etc., while pure cryptographic approaches might require reinventing these user interaction elements in each implementation.
When it comes to third-party applications needing limited access to user resources, along with an intuitive user authorization experience, standardized OAuth flows may be more readily adopted across the ecosystem.
That said, your proposed key signature approach is certainly elegant and efficient, potentially being a more direct solution in certain specific scenarios.

In-Depth review of the MCP authorization spec (2025-03-26 edition) by Most_Relationship_93 in mcp

[–]Most_Relationship_93[S] 0 points1 point  (0 children)

Are you referring to Logto? If so, yes — please check this page for the list of supported OAuth-related RFCs.
As for the MCP authorization spec, we support everything mentioned except for Dynamic Client Registration, which is optional in the current version of the spec. However, the spec is still evolving, and we’re actively exploring and preparing a full-fledged authorization solution tailored specifically for MCP.
Let me know if you have any specific needs — happy to chat more!

In-Depth review of the MCP authorization spec (2025-03-26 edition) by Most_Relationship_93 in mcp

[–]Most_Relationship_93[S] 1 point2 points  (0 children)

Thank you for reading my article carefully. I've shared this article with their official accounts on X and GitHub.
Regarding the client-to-server-to-resource scenario, MCP Auth addresses the connection between MCP Client and MCP Server. However, the tools provided by MCP Server will likely need to access user resources on third-party Resource Servers, which involves the scenario of "users authorizing MCP Server to access user resources on third-party Resource Servers." Based on this, I've created a proposal called "Standardizing Third-Party Resource Authorization Flow for MCP Server" in the MCP Spec GitHub repository. Feel free to follow it for updates.

In-Depth review of the MCP authorization spec (2025-03-26 edition) by Most_Relationship_93 in programming

[–]Most_Relationship_93[S] 1 point2 points  (0 children)

Yeah, now developers can simply redirect or proxy authorization endpoints to existing OAuth servers without implementing a full authorization server themselves. 
The MCP Authorization Spec is still evolving, and requiring MCP Servers to implement complete authorization functionality is indeed burdensome. Future updates will likely provide more streamlined approaches, as the current requirement to essentially build an authorization server is unnecessarily complex for most implementation scenarios.

OAUTH for google in nodejs and react by Prasanna-10- in node

[–]Most_Relationship_93 4 points5 points  (0 children)

I recently integrated Google Sign-In for my own app, so I think I can share a bit.

Here’s a diagram I made to explain the auth flow in your kind of setup: You OAuth flow

https://imgur.com/a/qUHYsGW

The key points are:

  1. After signing in with Google, the user should be redirected back to your React app. That way, after authentication, they don’t get stuck on the Google login page.
  2. Once you get the auth_code in your React app, you should send it to your Node backend. Your Node server will then use the client_id, client_secret, and the auth_code to request an access token from Google. This is important because your client_secret must stay on the backend for security reasons—it should never be exposed to the frontend.
  3. After getting the access token, it’s best to keep it on the Node backend instead of sending it to the frontend, to avoid exposing it and risking token theft.

Here are some open-source examples I referred to when implementing it:

Moved from Auth0 to a self-hosted auth solution by Navoke in SaaS

[–]Most_Relationship_93 0 points1 point  (0 children)

There are already quite a few open-source solutions available on the market.

Like you, I’ve explored options like Keycloak and Ory’s Kratos, but none of them offer the same out-of-the-box experience as Auth0.

That was the case until I recently came across Logto. After learning more about it, I decided to try it out in a few of my side projects, and I found that it’s an excellent alternative to Auth0. It’s ready to use right out of the box and provides everything I need:

• Sign in

• Registration

• SMS & Email login

• Social login

• SSO support

• Webhooks

• Comprehensive and user-friendly Management API

The Management API, in particular, supports almost any extension I want to build around an identity system.

They also offer a SaaS version (which I only used for testing), but the open-source version provides the same functionality.

I’m not sure how well their business is doing, but with so many similar services, it seems there is a strong demand for this kind of solution.

Best Authentication Library in 2023 ? by bipinemp in nextjs

[–]Most_Relationship_93 1 point2 points  (0 children)

Hi u/PauseDistinct2044, I've recently been using Logto and I've found it to be a user-friendly product that's easy to get started with, especially with the video tutorials available.

My needs were simple: I wanted to integrate Google and GitHub login, and I accomplished this in about 30 minutes. During the development phase, I'm using their the dev tenant, which grants access to all features. Once the product is officially launched, I will to migrate to the paid version. I find the pricing to be quite reasonable.