Microsoft 365 の大量のメール用の OAuth 認証

OAuth 認証を使用して SMTP プロトコルに接続し、Office 365 ユーザーの電子メールデータにアクセスする方法を説明します。

以下に説明する SMTP プロトコルの OAuth2 サポートは、Microsoft 365 (Office on the web を含む) と Outlook.com の両方のユーザーが利用できます。

OAuth 2.0 プロトコルに慣れていない場合は、「Microsoft ID プラットフォームでの OAuth 2.0 プロトコルの概要」を参照してください。 OAuth 2.0 プロトコルを実装してユーザーを認証し、セキュリティで保護された API にアクセスする Microsoft 認証ライブラリ (MSAL) の詳細については、「 MSAL の概要」を参照してください。

アプリケーションを登録する

OAuth を使用するには、アプリケーションを Microsoft Entra に登録する必要があります。

「Microsoft ID プラットフォームにアプリケーションを登録する」に記載されている手順に従って、新しいアプリケーションを作成します。

少なくともクラウドアプリケーション管理者として Microsoft Entra 管理センターにサインインします。
[ID]>[アプリケーション>] を参照しアプリの登録 [新しい登録] を選択します。
アプリケーションの表示名を入力します。アプリケーションのユーザーは、サインイン時など、アプリを使用するときに表示名が表示される場合があります。表示名はいつでも変更でき、複数のアプリの登録で同じ名前を共有することができます。アプリ登録の自動生成されたアプリケーション (クライアント) ID は、表示名ではなく、ID プラットフォーム内でアプリを一意に識別します。
登録後、いくつかの ID が作成されます。そのうちのいくつかは、後で OAuth 2.0 トークンを取得するために必要になります。

API アクセス許可を追加する

左側のメニューで、[ API アクセス許可 ]、[ アクセス許可の追加] の順に選択します。
organizationで使用している API に移動し、Office 365 Exchange Onlineを検索します。
[ API アクセス許可の要求] で、[ アプリケーションのアクセス許可]、[ Mail.Send]、[ アクセス許可の追加] の順に選択します。

注:

Mail.Send アプリケーションのアクセス許可は、すべての Exchange メールユーザーから電子メールを送信する機能を許可しません。説明した構成に従って、アプリケーションが Exchange アプリケーションのアクセス制御を通じて他のメールユーザーに対して明示的に承認されていない限り、HVE アカウントタイプのメールユーザーのみがメールを送信できます。構成に応じて、これは次のいずれかを使用して適用されます: アプリケーションアクセスポリシー (レガシ)、または Exchange Online のアプリケーションのロールベースの Access Control。
API アクセス許可を追加した後、管理者は [管理者の同意を付与する] を選択する必要があります。

アプリシークレットでアプリケーションのアクセス許可を使用するため、レガシ OAuth サードパーティアプリケーションを許可する委任アクセス許可とアプリケーションアクセス許可の両方をサポートしています。

アクセス許可の委任:

[API のアクセス許可] タブで、Office 365 Exchange Online\Delegated Permissions から Mail.Send API アクセス許可を追加します。
[ API のアクセス許可 ] タブで、[ 管理者の同意の付与] を選択します。
[ 認証 ] タブで、[ パブリッククライアントフローを許可する] を有効にします。
HVE メールユーザーの資格情報を使用して、対象ユーザー https://outlook.office.com/.defaultのトークンを要求します。

アプリケーションのアクセス許可:

[API のアクセス許可] タブで、[Office 365 Exchange Online\Application アクセス許可] から Mail.Send API アクセス許可を追加します。
[ API のアクセス許可 ] タブで、[ 管理者の同意の付与] を選択します。
[ 証明書 & シークレット ] タブで、新しいクライアントシークレットを追加します。
クライアントシークレットを使用して、対象ユーザー https://outlook.office.com/.defaultのトークンを要求します。

OAuth アクセスを許可されたアプリケーションに制限する

High Volume Email では、OAuth 認証を特定の Microsoft Entra ID アプリケーションセットに制限することをサポートしています。これにより、不正または意図しないアプリケーションが HVE アカウントを使用するのを防ぎ、不正使用や予期しない請求のリスクを軽減します。デフォルトでは、有効な OAuth 資格情報と必要な Exchange Online アクセス許可を持つアプリケーションは、HVE に対して認証できます。許可されたアプリケーションを使用すると、特定の HVE アカウントを使用して電子メールを送信することを許可するアプリケーションを明示的に定義できます。

許可されたアプリケーションのしくみ

HVE アカウントに対して許可されたアプリケーションが構成されている場合:

OAuth 認証中に、HVE はアクセストークン内のアプリケーション ID を検証します。
HVE アカウントに対して明示的に許可されているアプリケーションのみが、正常に認証できます。
他のアプリケーションからの認証要求は拒否されます。検証は、OAuth トークンの取得に使用される Microsoft Entra ID アプリケーションのサービスプリンシパル ID (オブジェクト ID) に基づいて行われます。

注:

許可されているアプリケーションは OAuth 認証にのみ適用されます。パスワードを使用した SMTP 基本認証には影響しません。

許可されたアプリケーションを構成する

許可されているアプリケーションは、Exchange Online PowerShell を使用して HVE アカウントごとに構成されます。 Microsoft Entra ID アプリケーションは、サービスプリンシパルの GUID を指定することで追加または削除できます。

注:

許可するアプリ ID を指定するには、アプリケーションの登録にエンタープライズアプリケーションノード (Azure portal) の概要ページのサービスプリンシパルオブジェクト ID を使用する必要があります。 [App Registrations] ノードの [Overview] ページのオブジェクト ID は使用しないでください。正しくないオブジェクト ID を使用すると、認証エラーが発生します。 OAuth を使用して IMAP、POP、または SMTP 接続を認証する方法の詳細をご覧ください。

許可されたアプリケーションを追加する

Add-HVEAppAccess -Identity HVEaccount@contoso.com -AppIds <service-principal-id-1>,<service-principal-id-2>

許可されたアプリケーションを削除する

Remove-HVEAppAccess -Identity HVEaccount@contoso.com -AppIds <service-principal-id-1>,<service-principal-id-2>

許可されたアプリケーションの表示

Get-HVEAccountSettings -Identity HVEaccount@contoso.com | Format-List *AllowedApps*

制限と動作

各 HVE アカウントには、最大 10 個の許可されたアプリケーションを構成できます。
HVE アカウントに許可されたアプリケーションが構成されていない場合、追加のアプリケーションレベルの制限は適用されません。

HVE SMTP プロトコル交換

SMTP サーバー接続を認証するには、クライアントがSASL XOAUTH2形式の AUTH コマンドで応答する必要があります。 SASL XOAUTH2 ユーザー名とアクセストークンを次の形式でエンコードします。

base64("user=" + userName + "^Aauth=Bearer " + accessToken + "^A^A")

^A Control + A (%x01) を表します。

たとえば、アクセストークン EwBAAl3BAAUFFpUAo7J3Ve0bjLBWZWCclRC3EoAA を使用してapplication@contoso.onmicrosoft.comにアクセスするSASL XOAUTH2形式は次のとおりです。

base64("user=application@contoso.onmicrosoft.com^Aauth=Bearer EwBAAl3BAAUFFpUAo7J3Ve0bjLBWZWCclRC3EoAA^A^A")

認証が成功するクライアントとサーバーのメッセージ交換の例:

[connection begins]

C: auth xoauth2

S: 334

C: dXNlcj1hcHBsaWNhdGlvbkBjb250b3NvLm9ubWljcm9zb2Z0LmNvbQFBdXRoPUJlYXJlciBFd0JBQWwzQkFBVUZGcFVBbzdKM1ZlMGJqTEJXWldDY2xSQzNFb0FBAQE=

S: 235 2.7.0 Authentication successful

[connection continues...]

認証エラーが発生するクライアントとサーバーのメッセージ交換の例:

[connection begins]

C: auth xoauth2

S: 334

C: dXNlcj1hcHBsaWNhdGlvbkBjb250b3NvLm9ubWljcm9zb2Z0LmNvbQFBdXRoPUJlYXJlciBFd0JBQWwzQkFBVUZGcFVBbzdKM1ZlMGJqTEJXWldDY2xSQzNFb0FBAQE=

S: 535 5.7.3 Authentication unsuccessful

Last updated on 2026-08-19