Exchange での認証と EWS

  • [アーティクル]

Exchange を対象とする EWS アプリケーションの適切な認証基準の選択に役立つ情報を紹介します。

認証は、Exchange Web サービス (EWS) アプリケーションの主要な部分の 1 つです。 Exchange Online、Office 365 の一部としての Exchange Online、および Exchange 2013 以降のオンプレミス バージョンの Exchange では、アプリケーションと Exchange サーバー間の通信をセキュリティで保護するため、標準的な Web 認証プロトコルをサポートしています。

Exchange Online を対象にしている場合は、選択した認証方法で HTTPS を使用して、アプリケーションが送信する要求と応答を暗号化する必要があります。 オンプレミスの Exchange サーバーでは HTTP を使用できますが、アプリケーションと Exchange サーバー間の通信をセキュリティで保護するために、アプリケーションが EWS のエンドポイントに送信するすべての要求で HTTPS を使用することをお勧めします。

Exchange には認証オプションが用意されており、次の中から選択できます。

  • OAuth 2.0 (Exchange Online のみ)

  • NTLM (オンプレミスの Exchange のみ)

  • 基本 (推奨されていません)

選択する認証方法は、Exchange Online またはオンプレミスの Exchange を使用しているかどうか、および OAuth トークンを発行できるサードパーティのプロバイダーへのアクセス権があるかどうかという、組織のセキュリティ要件によって異なります。 この記事では、アプリケーションに適切な認証基準を選択するうえで役立つ情報を提供します。

OAuth 認証

すべての新しいアプリケーションで OAuth 標準を使用して、Exchange Online サービスに接続することをお勧めします。 アプリケーションに OAuth を実装するためには追加の作業が必要ですが、基本認証に勝るセキュリティ上の利点はそれに見合う価値があります。 ただし、レコードに関しては、認識しておくべきデメリットもいくつかあります。

表 1. OAuth を使用するメリットとデメリット

メリット 欠点
OAuth は業界標準の認証プロトコルです。

認証はサードパーティのプロバイダーによって管理されます。 アプリケーションで Exchange の資格情報を収集して保存する必要はありません。

アプリケーションは認証プロバイダーから不透明なトークンを受信するだけなので、心配の種は少なくて済みます。そのため、アプリケーションでセキュリティ違反があっても、トークンが公開されるだけでユーザーの Exchange 資格情報が公開されることはありません。
OAuth はサード パーティの認証プロバイダーに依存しています。 このためユーザーの組織や顧客に追加のコストが発生します。

OAuth 標準の実装は基本認証の実装よりも困難です。

OAuth を実装するには、認証プロバイダーと Exchange サーバーの両方にアプリケーションを統合する必要があります。

欠点を最小限に抑えるために、Microsoft Microsoft Entra認証ライブラリ (ADAL) を使用して、クラウドまたはオンプレミスのActive Directory Domain Services (AD DS) に対するユーザーの認証を行い、Exchange サーバーへの呼び出しをセキュリティで保護するためのアクセス トークンを取得できます。 Exchange Onlineには、ADAL でサポートされているMicrosoft Entra サービスによって発行されたトークンが必要です。ただし、任意のサードパーティ ライブラリを使用できます。

EWS アプリケーションで OAuth 認証を使用する方法の詳細については、次のリソースを参照してください。

NTLM 認証

NTLM 認証が使用できるのは、オンプレミスの Exchange サーバーのみです。 会社のファイアウォールの内側で実行されるアプリケーションに対しては、NTLM 認証と .NET Framework 間の統合で、アプリケーションを認証するための組み込みの手段を用意しています。

表 2. NTLM 認証を使用するメリットとデメリット

メリット 欠点
“追加設定なし” で Exchange サーバーで機能する。 Exchange 管理シェル コマンドレットを使用して、Exchange サービスへのアクセスを構成できる。

.NET Framework の CredentialCache オブジェクトを使用して、ユーザーの資格情報を自動的に取得する。

オンプレミスの Exchange サーバーへの認証にログオン ユーザーの資格情報を使用するコード サンプルが利用可能。
ユーザーは、NTLM 認証を使用するためにドメインにログオンする必要がある。

ユーザーのドメイン アカウントに関連付けられていないメール アカウントへのアクセスが困難。

サービス アプリケーションに、NTLM 認証を利用するためのドメイン アカウントが必要。

基本認証

基本認証は、クライアント アプリケーションに対して基本的なレベルのセキュリティを提供します。 すべての新しいアプリケーションで認証に NTLM または OAuth プロトコルを使用することをお勧めします。ただし、状況によっては、基本的な認証がアプリケーションに適した選択になる場合があります。

表 3. 基本認証を使用するメリットとデメリット

メリット 欠点
“追加設定なし” で Exchange サーバーで機能する。 Exchange 管理シェル コマンドレットを使用して、Exchange サービスへのアクセスを構成できる。

Windows アプリケーションで、ログオン ユーザーの既定の資格情報を使用できる。

基本認証を使用して EWS を呼び出す方法を示す多数のコード サンプルが利用可能。
アプリケーションでユーザーの資格情報を収集して保存することが必要。

すべてのユーザーが基本認証を使用するようにさせるには、NTLM 認証を無効にする必要がある。

アプリケーションでセキュリティ違反が発生した場合、攻撃者にユーザーのメール アドレスとパスワードが漏洩する可能性がある。

基本認証が、ユーザーの組織と顧客のセキュリティ要件を満たしているかどうかを判断する必要があります。 基本認証は、簡単なテストやデモ アプリケーションなどで、詳細なセットアップ タスクを行わないようにする場合に、最適な選択肢になることがあります。

注:

Exchange Online に接続するための EWS の基本認証はサポートされていません。 すべての新規または既存の EWS アプリケーションで OAuth 認証を使用して、Exchange Online に接続します。 EWS の OAuth 認証は、Microsoft 365 の一部として Exchange Online でのみ利用可能です。 OAuth を使用する EWS アプリケーションは、最初に Microsoft Entra に登録する必要があります。

関連項目