[Epic] Enabling authenticated API calls from Kiota API plugins

[maisarissi]

Is your feature request related to a problem? Please describe the problem.

Enabling Authenticated API calls from API Plugins

As of today, Kiota generate plugins with "Auth None" information, which is great to call APIs that doesn't require authentication. This feature aims to empower developers with the ability to generate plugins that call APIs requiring authentication.

Use Cases

• A developer wants to create a plugin that calls an API, which requires authentication. The OpenAPI description has no auth information. They use Teams developer portal to create their auth registration. They use Kiota VS Code extension to create an API Plugins based on their OpenAPI description and to configure the authentication flow within the plugin.
• A DevOps engineer/Admin needs to deploy a plugin that interacts with a secure API. The OpenAPI description has no auth information. They rely on Kiota CLI to generate a plugin and to provide the authentication.
• A developer wants to create a plugin for endpoints that don't require authentication using Kiota extension.
• A DevOps engineer/admin wants to create a plugin from the Kiota CLI for endpoints that don't require authentication.
• A developer wants to create a plugin based an OpenAPI description with auth information. They use Kiota VS Code Extensions to create the plugin. The extension should infer the type of auth but still provide ways to configure the auth.
• A DevOps engineer/admin creates a plugin based an OpenAPI description with auth information. They use Kiota CLI to do it. One should only be able to create a plugin if the provided auth matches the OpenAPI description

Requirements

• Requirement 1: Kiota CLI must include a way for one to provide authentication type and reference id when generating plugins.
• Requirement 2: Based on selected paths, ensure the authentication is supported by Copilot. So far, Copilot only accepts oauth, bearer token and apikey. Kiota should also let the user know when the API auth is not supported.
• Requirement 3: Create a developer-friendly interface for plugin authentication configuration in Kiota Visual Studio Code Extension.
• Requirement 4: When the selected paths (endpoints) of the API doesn't require authentication, Kiota should create plugins with "auth none".
• Requirement 5: When the OpenAPI description has auth information, Kiota should validate whether the type of authentication in the plugin it is the same as the OpenAPI description and let the user know otherwise.

Additional context

No response

Tasks

Beta Give feedback

1. When the selected paths (endpoints) of the OpenAPI doesn't require authentication, Kiota should create plugins with auth object as none #5069
   enhancement vscode-extension +2
2. Kiota needs validate the security scheme and let the user know the only accepted methods are OAuth2, HTTP+Bearer Token and OpenId Connect #5071
   area:authentication enhancement generator type:enhancement +4
   
3. If the security scheme is provided, Kiota should use it to create the right auth object #5070
   area:authentication enhancement generator +3
   
4. Kiota CLI must include a way for one to provide authentication type and reference id when generating plugins #5072
   area:authentication enhancement generator +3
   
5. [Epic] Validation rules for Plugin Generation in Kiota #5162
   8 of 8
   Epic WIP +2
6. Kiota should have a developer-friendly way of providing auth information in the VS Code extension #5073
   area:authentication enhancement type:enhancement vscode-extension +4
7. [Plugin generation] Kiota should warn users when api contains unsupported auth flows #5403
   WIP type:bug vscode-extension +3
   

[baywet]

Thanks for creating this. Here is my feedback: this is probably more an epic that a feature. And the requirements are probably user stories. I suggest we break this in smaller pieces, and start by addressing requirement 4 as it's a low hanging fruit.
Thoughts?

[maisarissi]

Yes, this is an epic. I was trying something new and was about to ask for feedback whether having epics like this helps! My idea is for us now to break down into user stories and then smaller tasks. I thought that epics like this one could help us organize all the efforts needed to implement "a feature" as a whole.
I would say the requirements 1 and 4 are the ones I believe we should start with, as having a way to provide auth type and reference id in CLI would also help already with secure APIs.

[maisarissi]

I have created 5 new issues and attached to this epic

[baywet]

@petrhollayms here I think we have misalignments. This epic is tagged for 1.8.1/GA but the last item on the checklist is in the backlog?

[petrhollayms]

Yes, this is often the case with epics though. We shall not be therefore reporting epics in Changelog etc. but the individual stories representing new features, capabilities and bug fixes.