Azure ADでは、AuthenticationContext.AcquireTokenAsync(resource, new ClientAssertionCertificate(_clientId, _cert))のような電話をかけると、正確に何が起こるのか不明です。クライアント証明書を使用してAcquireTokenAsyncコールを実行するとどうなりますか？
証明書のどの部分が交換されるのですか？
チャレンジ/レスポンスは起こっていますか？
クライアントの一部として必要な秘密鍵はありますか？
質問に対する回答を見つける方法は2通りあります。 1つは、オープンソースなので、source code on GitHubのMicrosoft Active Directory認証ライブラリ（ADAL）を参照することです。もう1つ（これはここで行います）は、AcquireTokenAsync(String, ClientAssertion)が生成するネットワーク要求を調べ、そこから後方に作業します。
Fiddler（または任意の他のトラフィックアナライザ）を使用して、我々は（読みやすくするためにフォーマット）、以下のようなものを見ることができます：
POST https://login.microsoftonline.com/{tenant-id}/oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
&resource=https%3A%2F%2Fgraph.windows.net
&client_id={app-id}
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1N...VE8wHSf-HZvGQ
それを破壊：
grant_type=client_credentialsこれは教えてくれるOAuth 2.0 Client Credentials Grantフローを使用してトークン要求を送信します。resource=https%3A%2F%2Fgraph.windows.netは、クライアントがアクセストークンを要求しているリソースのURIを示します。この場合は、Azure AD Graph API用です。client_id={app-id}は、client identifierです。 Azure ADでは、これは登録されたアプリケーションのアプリIDです。client_assertion_typeとclient_assertionの存在は、クライアントが認証にassertionを使用していることを示している：
client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearerは、使用されているクライアント・アサーション署名JSON Web Token（JWT）であることを述べています。client_assertion=eyJhbGciOiJSUzI1N...VE8wHSf-HZvGQは、前述の署名付きJWTトークンです。認可サーバ（例えば、Azure AD）は内容を検証し、実際に問題のクライアントに対して認可された証明書によってトークンが署名されたことをチェックする。だから、、何ADALが行うことは次のとおりです。
AcquireTokenAsyncの間、証明書の拇印のみが提供されます（認可サーバーが対応する公開鍵を検索するのに役立つJWTヘッダーに含まれています）。 JWTの署名は、クライアントが秘密鍵を所有していることを証明するものです。ただし、の前にAcquireTokenAsync(String, ClientAssertion)を正常に使用することができます。あなた）はAzure ADに証明書の公開鍵を提供する必要があります。
ここではチャレンジ/レスポンスはありません。トークンは、クライアントによって開始された単一の要求で取得されます。
（ADALがあることに注意してください：より多くの詳細については
、あなたは、このすべての実装は、その基準を見直すことができます上記のすべてがo ADALがトークンキャッシュ内に有効なアクセストークンを見つけられない場合はnly。AuthenticationContext.TokenCache.Clear()を使用して実験用のキャッシュをクリアすることができます）。
この素晴らしいありがとう、フィリップ！ –