Allow Interactive Browser Authorization for Machines without Azure CLI

[srathi-msft]

Hi!

I would like to adapt the auth logic to fallback to interactive browser credentials if the Azure CLI is not present on the client machine.

This caters to users working in protected environments who have restricted access to install things on their machines.

Is this something that'll help with the project's vision?

Thanks!

[danhellem]

I don't think we plan to provide this in the local MCP Server. But added the right folks to respond.

[srathi-msft]

Have removed the PR as it is against the contributor guidelines to contribute to an unapproved issue.

Please let me know if this aligns with the project, then I'll reopen it.

[danhellem]

@srathi-msft we talked offline and I think we agree this is worth exploring. Feel free to create a draft PR and our team can review. Thanks.

[srathi-msft]

I've reopened the PR #307. Please let me know if you need anything.

[dsmalik]

@srathi-msft While the fallback is good, can we make it configuration based so that we can specify what form of authorization is required when starting the mcp server using arguments? Just a thought, i am fine with current change as well since it helps me not depend on Azure cli installation.

For example - npx -y @azure-devops/mcp "ADO_ORG" "Auth Scheme to use"

Auth scheme which can be Interactive/PAT or other supported. I do see @azure/identity package does offer support for different schemes but they are not used/exposed by this mcp server.

[DavidNorena]

I believe there could be an easier approach for implementation and not to have to worry about an specific credentials, after reading more the azure identity sdk for javascript more they have this piece

https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/identity/identity/src/credentials/environmentCredential.ts#L89 as an example, which will load the credentials at run time

And this project already have this piece of code

  if (process.env.ADO_MCP_AZURE_TOKEN_CREDENTIALS) {
    process.env.AZURE_TOKEN_CREDENTIALS = process.env.ADO_MCP_AZURE_TOKEN_CREDENTIALS;
  } else {
    process.env.AZURE_TOKEN_CREDENTIALS = "dev";
  }

My bet is just allow the AZURE_TOKEN_CREDENTIALS to be an argument for this process instead of environment variable, so it can be overriden at runtime and then you can leverage this code

https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/identity/identity/src/credentials/defaultAzureCredential.ts#L128

then we can have a bunch of credentials, without explicitly modifying the core code of this project

just changing the value of AZURE_TOKEN_CREDENTIALS at runtime and you allow the identity sdk to take care of that

It just an assumption but I believe is a simpler and easier approach for this, and opens the door to real use case scenarios :)

[srathi-msft]

@srathi-msft While the fallback is good, can we make it configuration based so that we can specify what form of authorization is required when starting the mcp server using arguments? Just a thought, i am fine with current change as well since it helps me not depend on Azure cli installation.

For example - npx -y @azure-devops/mcp "ADO_ORG" "Auth Scheme to use"

Auth scheme which can be Interactive/PAT or other supported. I do see @azure/identity package does offer support for different schemes but they are not used/exposed by this mcp server.

@dsmalik The initial idea was to have the interactive auth as a command line argument. The rationale for the current implementation is that

• If a user does not have Azure CLI, they will eventually fallback to interactive credentials.
• If a user has Azure CLI, then their default flow is not affected. If they encounter some auth error with Azure CLI, then they will have an option to fall back to.

The above design catered to the use case mentioned in the issue with details abstracted from the user-side
users working in protected environments who have restricted access to install things on their machines.

We can explore the (optional) explicit specification of the auth type in command line arguments. It has the advantage of giving the user more control. So users by default can use a chain of credentials with fallback, with an option to use a particular credential if specified. What do you think?

[srathi-msft]

I believe there could be an easier approach for implementation and not to have to worry about an specific credentials, after reading more the azure identity sdk for javascript more they have this piece

https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/identity/identity/src/credentials/environmentCredential.ts#L89 as an example, which will load the credentials at run time

And this project already have this piece of code

  if (process.env.ADO_MCP_AZURE_TOKEN_CREDENTIALS) {
    process.env.AZURE_TOKEN_CREDENTIALS = process.env.ADO_MCP_AZURE_TOKEN_CREDENTIALS;
  } else {
    process.env.AZURE_TOKEN_CREDENTIALS = "dev";
  }

My bet is just allow the AZURE_TOKEN_CREDENTIALS to be an argument for this process instead of environment variable, so it can be overriden at runtime and then you can leverage this code

https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/identity/identity/src/credentials/defaultAzureCredential.ts#L128

then we can have a bunch of credentials, without explicitly modifying the core code of this project

just changing the value of AZURE_TOKEN_CREDENTIALS at runtime and you allow the identity sdk to take care of that

It just an assumption but I believe is a simpler and easier approach for this, and opens the door to real use case scenarios :)

@DavidNorena I believe EnvironmentCredential is part of the credential chain of DefaultAzureCredential. Though I'm not sure if it works, since DefaultAzureCredential seemed to fail without Azure CLI. Will check.

Yes, the latter approach could be used to give the user control over the auth method. Thanks.