The standard has a page on authorization[0], though it's not particularly easy to read for someone not well-versed with OAuth.
In short, MCP just uses plain boring oauth, like any other oauth authorization. Like when you authorize an app to access your google calendar. The only difference is that instead of accessing your normal API, they access your MCP http endpoint. Each connection to that endpoint will pass the Authorisation header with an oauth token, which you can resolve to a user on your side. Same as you would with normal OAuth.
One cool bit is that MCP providers are supposed to support OAuth2 Dynamic Client Registration, which means that e.g. Claude can provision an OAuth2 client in your app programmatically (and get a client_id/client_secret that it can use for authorization flows).
When you add an MCP server to your Claude organization, you just add the MCP server. Each user will have to go through the integration's OAuth2 authorization flow separately.
[0]: https://modelcontextprotocol.io/specification/2025-03-26/bas...
Check out https://aaronparecki.com/2025/05/12/27/enterprise-ready-mcp - there are some great ideas there on how this can be simplified even more in the future.
I have built a couple using the spec from a month ago. It works alright.
A lot of bad decisions are in the official implementations. For instance not using native Request / Response types in node, so you’re forced to write a bunch of garbage code to convert it, or install express just to use an mcp server.
If I had the time I’d really make my own mcp implementation in typescript at least.
I find most of the implementations to be so over engineered and abstracted on what could be simple function calls on top of the built in language
For simple stuff like a json file that returns the location of your auth routes, you need to add a “middleware”
When in reality you can just make a route and explicitly return that information.
Every piece is some new abstraction it feels vibe coded.
Most of the standard and implementation is focused in the vision of models and clients that automatically handle the tool overhead, while in reality everything that is related to MCP requires tons of boilerplate/middleware/garbage code.
For example, when you try to integrate with AI model that supports function calling in the backend and want to use MCP server to enhance the model.
I haven't figured that out yet. Maybe you would need to use Client-Initiated Backchannel Authentication Flow ?
There's basically a couple of different ways to implement an MCP server - for this demo it's a local binary that communicates over stdio, so no OAuth process is taking place. It's only meant to run on your local machine.
To make the demo simpler to explore and understand, the binary loads it's configuration (SnapTrade API client id, secret, and username and secret) from a .env file that you populate with your credentials which allows it to fetch the right data.