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>Applications>アプリの登録 に移動し、[新しい登録] を選択します。
アプリケーションの表示名を入力します。アプリケーションのユーザーは、サインイン中など、アプリを使用するときに表示名が表示される場合があります。表示名はいつでも変更でき、複数のアプリ登録で同じ名前を共有できます。アプリの登録によって自動的に生成されるアプリケーション (クライアント) 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\委任されたアクセス許可から Mail.Send API アクセス許可を追加します。
[ API のアクセス許可 ] タブで、[ 管理者の同意の付与] を選択します。
[ 認証 ] タブで、[ パブリッククライアントフローを許可する] を有効にします。
HVE メールユーザーの資格情報を使用して、対象ユーザーhttps://outlook.office.com/.defaultのトークンを要求します。

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

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

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

大量の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 ポータル) の [概要] ページにあるサービスプリンシパルオブジェクト ID をアプリケーション登録に使用する必要があります。 [アプリの登録] ノードの [概要] ページからオブジェクト 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 サーバー接続を認証するには、クライアントが AUTH コマンドを SASL XOAUTH2 形式で応答する必要があります。 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-03-27