undefined | Better HN

0 pointskentonv9mo ago0 comments

This library helps implement both the resource server and authorization server. Most people understand these two things to be, collectively, the "provider" side of OAuth -- the service provider, who is providing an API that requires authorization. The intent when using this library is that you write one Worker that does both. This library has no use on the client side.

This is intended for building lightweight services quickly. Historically there has been no real need for "lightweight" OAuth providers -- if you were big enough that people wanted to connect to you using OAuth, you were not lightweight. MCP has sort of changed that as the "big" side of an MCP interaction is the client side (the LLM provider), whereas lots of people want to create all kinds of little MCP servers to do all kinds of little things. But MCP specifies OAuth as the authentication mechanism. So now people need to be able to implement OAuth from the provider side easily.

> Experience with the RFCs but have not been able to correctly name it.

These docs are written for people building MCP servers, most of whom only know they want to expose an API to AIs and have never read OAuth RFCs. They do not know or care about the difference between an authorization server and a resource server.

0 comments

EtienneK9mo ago

> Most people understand these two things to be, collectively, the "provider" side of OAuth

Citation needed. As another commenter already noted, the term "Provider" is rarely used in OAuth itself. When it is mentioned, it's typically in the context of OpenID Connect, where it refers specifically to the Authorization Server - not the Resource Server.

> the service provider, who is providing an API that requires authorization

That’s actually the Resource Server.

I understand that the current MCP spec [1] merges the Authorization Server and Resource Server roles, similar to what your library does. However, there are strong reasons to keep these roles separate [2].

In fact, the MCP spec authors acknowledge this [3], and the latest draft [4] makes implementing an Authorization Server optional for MCP services.

That’s why I’m being particular about clearly naming the roles your library supports in the OAuth flow. Going forward, MCP servers will always act as OAuth Resource Servers, but will only optionally act as Authorization Servers. Your library should make that distinction explicit.

[1]: https://modelcontextprotocol.io/specification/2025-03-26/bas...

[2]: https://aaronparecki.com/2025/04/03/15/oauth-for-model-conte...

[3]: https://github.com/modelcontextprotocol/modelcontextprotocol...

[4]: https://modelcontextprotocol.io/specification/draft/basic/au...

j / k navigate · click thread line to collapse