EtienneK
Canonical Builds Steam Snap for Ubuntu ARM64 Leveraging FEX
Keycloak: Open-Source Identity and Access Management
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...
What is the "provider" side? OAuth 2.1 has no definition of a "provider". Is this for Clients? Resource Servers? Authorization Server?
Quickly skimming the rest of the README it seems this is for creating a mix of a Client and a Resource Server, but I could be mistaken.
> To emphasize, this is not "vibe coded". Every line was thoroughly reviewed and cross-referenced with relevant RFCs, by security experts with previous experience with those RFCs
Experience with the RFCs but have not been able to correctly name it.
The E71 was arguably Nokia's best phone ever; and it was indeed better than the iPhone 3G. But Nokia just couldn't keep up the momentum.
I bought into the idea of the iPad Pro as a coding device 4 years ago; only to have been left very disappointed. And it seems nothing has really changed (although the M series iPads do at least support full screen external monitors now - mine still has black bars).
I won't consider an iPad Pro until I can actually use it as a development laptop replacement. I still see use for the non-pro iPads in my life; but not the Pro.
Please elaborate.