search

continuedev / continue

⏩ Continue is the leading open-source AI code assistant. You can connect any models and any context to build custom autocomplete and chat experiences inside VS Code and JetBrains
https://docs.continue.dev/
Apache License 2.0
18.87k stars 1.6k forks source link

OAuth2 credential support for Azure OpenAI using azure-identity #1326

Open cccs-eric opened 5 months ago

cccs-eric commented 5 months ago

Validations

Problem

As of now, the only supported way to authenticate to an Azure OpenAI endpoint in Continue is by using an API key. This works well for OpenAI where each user has its own API key, but in Azure, we are limited to 2 keys per endpoint. We have to share those keys with pretty much everyone in the organization and it is impossible to audit users since API key are not bound to user identities. A much better way to audit and control access to the Azure OpenAI endpoint is to authenticate the user using one of the many ways supported by Azure. It would be nice if we could configure Continue to use something else than API keys to access an Azure OpenAI endpoint.

Solution

Azure supports a few ways to authenticate a user, an application or a principal. Fortunately, Azure provides a convenient Javacript library named azure-identity. Using this, we can request an OAuth2 access token that we can use as a Bearer token when accessing the OpenAI endpoint. In other words, this access token becomes your temporary, personal API key.

Via DefaultAzureCredential, Microsoft provides a chain of TokenCredential classes that you can use to easily find an authentication method that is suitable to you. Under the hood, this class is configured to try a few predefined Credential classes until one works, but it is possible to bypass this method and use a specific Credential instance, or even provide your own.

I was able to make it work using DefaultAzureCredential, but I would need some guidance on how to make it fit nicely in the current codebase. For my use-case, I would also need to be able to provide my own implementation of TokenCredential since we have a custom requirement for user-impersonation using an external vault. The details of this is irrelevant to this issue, beside the fact that I'll need a way to provide my own custom implementation.

Does this ask seem reasonable, and inline with Continue's authentication philosophy?

gcwngo commented 2 weeks ago

@cccs-eric has there been any progress to support this enhancement? I'm interested in implementing something similar, what has worked for you in the meantime?

cccs-eric commented 2 weeks ago

Not that I know of. We have been using shared keys for the tiem being, which is not ideal. 😞