Please see:
|
if (_authenticationFactory != null) |
There shouldn't be a dependency on _authenticationFactory in this current state to add the auth token to the http request. Since clients can handle token challenges, it should be decoupled from the logic that the login-tooling of MCPify provides. Specifically, this counts for the OAuthAuthorizationCodeAuthentication provider, since that's the one that clients can officially handle. Maybe introduce a ClientProvidedAuthentication for the IAuthenticationProvider interface, that does nothing except pass the auth token (created by the client) to the http request.
Right now, if you omit OAuthAuthorizationCodeAuthentication, but let the client handle the authorization code flow, it won't be passed to the API backend. Thus, we're forced to keep this object in, as a placeholder, to have a working solution.
Please see:
MCPify/MCPify/Tools/OpenApiProxyTool.cs
Line 77 in 54bac73
There shouldn't be a dependency on
_authenticationFactoryin this current state to add the auth token to the http request. Since clients can handle token challenges, it should be decoupled from the logic that the login-tooling of MCPify provides. Specifically, this counts for theOAuthAuthorizationCodeAuthenticationprovider, since that's the one that clients can officially handle. Maybe introduce aClientProvidedAuthenticationfor theIAuthenticationProviderinterface, that does nothing except pass the auth token (created by the client) to the http request.Right now, if you omit
OAuthAuthorizationCodeAuthentication, but let the client handle the authorization code flow, it won't be passed to the API backend. Thus, we're forced to keep this object in, as a placeholder, to have a working solution.