Replies: 3 comments 2 replies
-
|
I asked a related question in #1524. What confuses me is I think there are meant to be two auth flows:
I think the June spec assumes that the MCP Server is often "owned" by MSFT so it auths both resources at once. But, when you are building your own MCP Server to access MSFT (or whomever yours is), that is now back to two flows. Whereupon, what is canonical? Should the Client accept the MSFT access tokens and then pass them in via headers to your MCP Server? Or should the MCP Server save its own tokens? What trips me up is adding multi-user to this. |
Beta Was this translation helpful? Give feedback.
-
|
Would any FastMCP guru be willing to get on like a Discord call with several of us to nut this out? |
Beta Was this translation helpful? Give feedback.
-
|
@4rpit... If I understand your scenario, I now have an answer based on going deep in all this. You're actually not running an MCP Server, you're building an "MCP Proxy Server" (MCP spec flow below). As in, you want this: And you need your server to auth with both the Client and the 3rd Party API resource? The trick is most auth documents assume that the MCP Server & the API Resource are the same organization. They are drawn as if Microsoft published its own MCP Server (the way Notion, Slack, Xero have their own). So the Client is only doing one, direct auth. Local STDIO obscures this because you won't do the Client to Server Auth... the tokens are used for the 3rd party. But most of us aren't MSFT. So that's why it is confusing. The Client isn't supposed to know about your 3rd party API. It is only trying to auth with the server. The server itself has to go handle auth with the 3rd party. Which means, your MCP Proxy Server needs to have its own DB, its own little auth callbacks, etc. Then, all the Client gives your Server is
|
Beta Was this translation helpful? Give feedback.
-
|
This image requires several reads |
Beta Was this translation helpful? Give feedback.
-
|
@GoodGuyGregory you're telling me! I have a simpler mental model for the above, now. You basically need "2 hops".
Once you get an access token, you always pass that in to your "MCP Proxy Server" to make API calls to Google, Outlook, etc. Anchor on this then ask where things go/return. In step 1, it *goes to the browser (that's what the authurl does). The user does their thing there. The browser then returns to your host/client for step 2 (that's what callback URI told it). Then in step 2 you go server-to-server with Microsoft/Google, say to do token exchange which returns the tokens you store. After that, you're just trying to get those tokens into your MCP Proxy during calls. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I am looking to understand the OAuth flow based on recent published specifications, specifically following the OAuth 2.0 flow (which can operate without DCR). My current understanding is that an MCP client communicates with an MCP server that exposes metadata about the authorization server. The client then uses this information to redirect to the authorization server, that does the user authentication, and sends tokens back.
I have a few questions regarding the management of tokens by standard clients (such as Claude Desktop or Cursor):
How do these clients manage the access token and refresh token once they have been obtained?
Is the access token passed with every request as a Bearer token in the Authorization header?
How do standard clients handle token refresh after expiry? Is the refresh token automatically requested, and what is the common practice especially for public clients?
Are there formal specifications or best practices that define how these standard client handle token storage, refresh flows, and what are the practice that should be followed on MCP server side ?
I plan to build an MCP server that secures the user token issued by the Identity Provider (IDP) and uses that same token to access underlying APIs within client tools. Any clarification, articles, or sample implementations addressing these aspects would be greatly appreciated.
Beta Was this translation helpful? Give feedback.
All reactions