You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support an end-user friendly OAuthAuthorizationCodeAuthenticator #2
In a perfect world, this library allows some kind of OAuthAuthorizationCodeAuthenticator, which not only should read from the OpenAPI OAuth 2.0 security segment to get the required values, such as these, but also allows for interactive authentication through prompting with the MCP server, allowing for each end-user to use their own credentials. This is equivalent to using a swagger ui or scalar ui, where you can interactively generate your oauth tokens and use them (in the browser front-end generated by the UI tooling).
Quick update: PKCE and client-credentials support are in (as of version 0.0.5-preview), and external OpenAPI specs (like your bank API) can be registered with the right token/authorize endpoints and subscription key.
Currently authentication is still triggered out-of-band (browser/device flow) with a shared token store, so it doesn’t yet offer a Swagger-UI-style interactive login per MCP user. We could add an MCP ‘login’ tool that returns a device-flow verification URL + user code (with per-session token storage), or an auth-code/PKCE URL handoff. Do you have a preference or any suggestions? We can try one approach and adjust based on feedbacks.
For device flow vs authorization code - I feel like authorization code flow is more commonly used. Device flow has been supported just recently in the OpenAPI spec: https://github.com/OAI/OpenAPI-Specification/releases/tag/3.2.0, this means there is little support for OpenAPI spec generators. I don't even think it's technically possible in asp.net APIs currently, since .net 10 only supports up to openapi 3.1.1 spec - unless you use a custom setup with the Microsoft.OpenAPI library.
There is still potential to have it even further simplified (like support for multiple auth providers in 1 API without duplicating tools, and not having to specify the provider details but getting them from the definition instead), but I'm already very happy with what I can do with it. 💯
Activity
abdebek commentedon Dec 7, 2025
Hi @erwinkramer ,
Quick update: PKCE and client-credentials support are in (as of version 0.0.5-preview), and external OpenAPI specs (like your bank API) can be registered with the right token/authorize endpoints and subscription key.
Currently authentication is still triggered out-of-band (browser/device flow) with a shared token store, so it doesn’t yet offer a Swagger-UI-style interactive login per MCP user. We could add an MCP ‘login’ tool that returns a device-flow verification URL + user code (with per-session token storage), or an auth-code/PKCE URL handoff. Do you have a preference or any suggestions? We can try one approach and adjust based on feedbacks.
erwinkramer commentedon Dec 7, 2025
@abdebek looks like some good progress, nice!
For device flow vs authorization code - I feel like authorization code flow is more commonly used. Device flow has been supported just recently in the OpenAPI spec: https://github.com/OAI/OpenAPI-Specification/releases/tag/3.2.0, this means there is little support for OpenAPI spec generators. I don't even think it's technically possible in asp.net APIs currently, since .net 10 only supports up to openapi 3.1.1 spec - unless you use a custom setup with the
Microsoft.OpenAPIlibrary.erwinkramer commentedon Dec 23, 2025
@abdebek just an update from my side, please see https://github.com/erwinkramer/bank-api?tab=readme-ov-file#run-the-mcp-server, i successfully implemented the library in a way that currently works for me, based on your last changes on
0.0.7-previewand your provided samples in the repo (much thanks for that!).There is still potential to have it even further simplified (like support for multiple auth providers in 1 API without duplicating tools, and not having to specify the provider details but getting them from the definition instead), but I'm already very happy with what I can do with it. 💯
erwinkramer commentedon Oct 29, 2026
@abdebek I decided to go ahead and create my own MCP project based on OpenAPI specs, see https://github.com/erwinkramer/enframe
This is exactly what I was looking for, took a few days but it's serving me well.