以前に書いたときよりたいぶ使いやすくなった（？）Managed Service Identity（MSI）ですが、Visual Studioでローカル開発をする際も簡単になっていました。

Azure上にデプロイすればMSIで自動的に良しなにしてくれますがローカルだとそのあたりの情報がないですよね。最近のVisual Studioであれば、この時に使用するアカウントを設定で指定することができます。
※Visual Studio 2017 （Update 5は拡張機能をインストール、Update 6以降は組み込みみたいです）
※参考：Service-to-service authentication to Azure Key Vault using .NET

ローカルデバッグなどの際は、ここで指定したアカウントのアクセストークンを使うようにAzureServiceTokenProviderが構成されます。便利ですね。

現時点の問題点

今時点で指定したアカウントが複数テナントに紐づいていたり（別テナントのサブスクリプションに権限がある）するとアクセストークンは取得できるけど実際にアクセスする際に401エラーになります。
回避するにはGetAccessTokenAsync()の引数にテナントIDを入れたりすればいいのですが、せっかくコードからキーやIDを取り除こうとしてるのにそんなことはしたくないですよね（本番環境でも指定しないといけなくなるし）
Visual Studioのアカウント設定にそれっぽい設定がありテナントのフィルタが行えるようなのでそちらを使ってみましょう。

ただし、フィルタされてるように見えて実際には（今のところ）されていないのでこの方法は使えません。（バグっぽいので報告はしたのですけど伝わるかどうか謎。。）

回避策の回避策

凄く面倒くさいですがAzureServiceTokenProviderの中でVisualStudioAccessTokenProviderを使ってるようで、そちらを見ると %LocalAppData%\.IdentityService\AzureServiceAuth\tokenprovider.json ファイルの情報を基に構成しているようです。
なのでJSONファイルを開いてArguments配列に–tenant とテナントIDを追加すれば一応OKです。

※使用する拡張機能毎に設定があるようなので適宜同じように修正しましょう

追記：回避策その2

AzureServiceTokenProviderの接続文字列でいろいろ構成できるのでそちらの方法を使う手もあります。ただコード内に埋め込むとやりたいことからずれるので、ローカル開発環境下では環境変数AzureServicesAuthConnectionStringを使うことでコードは変えずに設定を変えることができます。

またAzureCLIを使って（az account set –subscription <subscription ID>して）指定することもできますが、AzureCLIよりVisualStudioのほうが優先度が高いためそのままではAzureCLIの設定を見てくれません。

AzureCLIの構成を使いたい場合は上述の環境変数に RunAs=Developer; DeveloperTool=AzureCli を指定すればAzureCLIの構成を利用するようになり、やりたいことが実現できます。（その他接続文字列のオプションはこちら）

まとめ

ちょっと面倒くさい個所があるかもしれませんが（使用アカウントの環境依存ではある）、MSIを使ってコードから秘密鍵やキーを撤廃しましょう。基本的にMSIか、MSI経由のKey Vaultからキーを取得するようにすれば誤ってコードに埋め込んでインターネットに公開、みたいなリスクも無くせます。