Add Authorization Flow for MCP client server host extension

[sberyozkin]

Fixes #26

Motivation and Context

It introduces an authorization flow extension for MCP client hosts such as traditional HTTP server applications

How Has This Been Tested?

This scenario has been described in the Quarkus blog post at https://quarkus.io/blog/secure-mcp-client/, and demoed in the Quarkus LangChain4j repository at https://github.com/quarkiverse/quarkus-langchain4j/tree/main/samples/secure-mcp-client-server.

This scenario is not Quarkus specific. Any HTTP server application that requires OAuth or OIDC login and needs to use AI Service with MCP to complete a user request may benefit from adapting this extension.

Breaking Changes

None

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

I'll appreciate any advice and recommendations from @localden, @D-McAdams, @PieterKas, @aaronpk and the community at large on how to finalize this extension proposal

[PieterKas]

@sberyozkin - if I understand this proposal correctly, your proposing a model in which the OAuth interactions are handled by the HTTP Server, and the Access Tokens are given to the MCP client, rather than having the MCP client obtain the access tokens from the OAuth server directly?

If that is the case, I think what your proposing here is not anything new in the context of OAuth or how authorizations is done, but rather an architectural change to MCP that separates out the OAuth Client from the MCP Client. To me this feels a bit like an implementation detail, at least from an interop perspective.

Can you expand a little on why it is necessary to formalise this separation between the OAuth client (the HTTP server in your case) and the MCP Client, rather than just treating it as an implementation detail?

[sberyozkin]

@PieterKas Thanks for having a look at this proposal,

If that is the case, I think what your proposing here is not anything new in the context of OAuth

Indeed, you are right

Can you expand a little on why it is necessary to formalise this separation between the OAuth client (the HTTP server in your case) and the MCP Client, rather than just treating it as an implementation detail?

We've seen some concerns that an HTTP server software that uses MCP client to access protected MCP servers with access tokens is not compliant with the main MCP Authorization specification, it can be problematic when a standard compliance is a must, and when convincing that it is an implementation detail is not easy.

I hope it can give OAuth2 aware HTTP server applications that use MCP clients internally an option to claim a compliance with this extension, and make it clearer to their users that MCP client plays a different role in the main and this extension authorization specifications.

The other thing is that with traditional HTTP applications that require OAuth2 logins, using a scope redirect parameter is a typical mechanism for requesting extra access token capabilities. I like the main Authorization spec's focus on a resource parameter to support protected MCP server invocations. This extension attempts to keep the resource parameter requirement in sync with the main specification, and might encourage existing HTTP server applications move to supporting a resource parameter faster.

I also have a RAR addition in mind where authorization_details might, for example, list not only a specific MCP server resource URL but also a specific tool, but if RAR does get adopted, it should probably start from the main specification.