Microsoft 365 では、SMTP Auth（基本認証）が廃止されることが決定しており、OAuth (先進認証) への切り替えが必要となっています。
今回は OAuth とはどういうものかや SMTP Auth の違いについて解説したいと思います。
- OAuth とは？
- OAuth の通信の流れ
- OAuth の特徴
- なぜOAuthは安全なのか？
- SMTP Auth とは？
- OAuth と SMTP Auth の違い
- なぜ、基本認証は廃止されるのか？
- OAuth で SMTP 送信するには？
- EntraID 管理画面で行うことは？
OAuth とは？
Microsoft 365 では、認証基盤として Microsoft Entra ID（旧 Azure AD）を利用しています。
OAuth とは、パスワードを直接渡さずにアクセス権を委任する仕組みです。
OAuthは「認証（Authentication）」ではなく、「認可（Authorization）」の仕組みです。
「このクライアントは、このリソースに、この範囲で、いつまでアクセスしてよいか」を安全に伝えるための アクセス委譲プロトコルです。
仕組みのイメージ
- ユーザーがサインイン
- Entra ID がアクセストークンを発行
- アプリはトークンを使って API にアクセス
パスワードそのものはアプリ側に保存されません。
OAuth の通信の流れ
OAuthは「どうやってトークンを手に入れるか」を Grant Type（フロー）として定義しています。
(A) Authorization Code Flow（ユーザーあり）
Client → Authorization Server → User Login
Client ←Authorization Code ← User Consent
Client → Token Endpoint → Access Token
Client → Resource Server (Bearer Token)
- Web / モバイルアプリ向け
- 最も安全
- ユーザー同意が前提
(B) Client Credentials Flow（ユーザーなし）
Client → Token Endpoint (client_id + secret)
Client ←Access Token
Client → Resource Server
- サーバー間通信
- バッチ・デーモン・SMTP OAuthなど
- ユーザーは登場しない
OAuth の特徴
① トークンベース認証
アクセストークンを使って認証を行います。
有効期限があり、リフレッシュトークンで更新可能です。
② 多要素認証（MFA）対応
MFA や条件付きアクセスと連携可能。
③ 細かいアクセス制御
アプリ単位で「Mail.Send」「Mailbox.Read」などのスコープを指定できます。
④ セキュリティが高い
パスワード漏洩リスクが大幅に低減。
なぜOAuthは安全なのか？
① パスワードを渡さない
パスワード漏洩 = 全権限 → OAuthでは起きない
② 最小権限（Scope）
- mail.send だけ許可
- mail.read は不可 → 被害半径が小さい
③ 短命トークン
- 漏れてもすぐ失効（数分〜1時間）
- Refresh Tokenで再発行（制御可能）
④ Resource Serverは認証を知らない
- APIは 署名検証だけ
- スケールしやすい
SMTP Auth とは？
SMTP Auth は、SMTP プロトコルでメール送信する際に、ユーザー名とパスワードで認証する方式です。
Microsoft 365 では、Exchange Online の SMTP クライアント送信で利用されます。
OAuth と SMTP Auth の違い
| 比較項目 | OAuth | SMTP Auth（Basic） |
|---|---|---|
| 認証方式 | トークン | ユーザー名＋パスワード |
| MFA対応 | 可能 | 原則不可 |
| セキュリティ | 高い | 低い（パスワード漏洩リスク） |
| 推奨度 | Microsoft推奨 | 廃止方向 |
| API利用 | Microsoft Graph など | SMTP のみ |
SMTP Auth
- アプリが ユーザーID＋パスワード を預かる
- アプリが 無制限アクセス権 を持つ
OAuth
- パスワードは 一切渡さない
- スコープ付き・期限付きトークンだけ渡す
なぜ、基本認証は廃止されるのか？
- パスワードスプレー攻撃に弱い
- 多要素認証が使えない
- レガシープロトコルは攻撃対象になりやすい
現在は OAuth 2.0 ベースのモダン認証が標準です。
OAuth で SMTP 送信するには？
OAuth で SMTP 送信する設定は、実はこの 3ステップ だけです。
- アプリを登録する（Microsoft Entra / 旧 Azure AD）
- OAuth の「鍵（アクセストークン）」を取得する
- SMTP でその鍵を使って送信する
Exchange Online で OAuth 送信するとは
「パスワードの代わりに、有効期限つきの“安全な鍵”を使ってSMTP でメールを送ること」です。
OAuth の構成要件
SMTP AUTH（クライアント送信、通常 TCP/587）で OAuth を使う場合
- SMTP サーバー：smtp.office365.com（STARTTLS）
- 認証方式：SASL XOAUTH2（ユーザー名 + Bearer Access Token を Base64 で送る）
- 事前条件：テナント/メールボックスで SMTP AUTH が許可されていること
SMTP AUTH は組織全体・メールボックス単位で無効化でき、無効だと使えません - トークン発行元：Microsoft Entra ID
OAuth を使うには アプリ登録が必要
ステップ1：アプリを登録する（OAuth の準備）
次に 「誰が OAuth を使うのか」を登録します。
これが アプリ登録 です。
「IMAP / POP / SMTP を OAuth で使うには、アプリ登録が必要」です。
この作業は「このプログラムは、Exchange Online に接続してもいいですよ」と Microsoft に登録する作業です。
登録後に手に入るもの
- アプリケーションID（Client ID） → OAuth の世界での「名札」
※この時点では、まだメールは送れません
ステップ2：メール送信用の「権限」を与える
OAuth では「何をしていいか」を スコープ（権限）で指定します。
SMTP 送信に必要な権限は、Microsoft が決めています。
SMTP 送信用の正式なスコープ
https://outlook.office.com/SMTP.Send
「このアプリは メール送信だけ していい」と許可を出しています。
※管理者が 同意（管理者同意） する必要があります
ステップ3：OAuth の「鍵（アクセストークン）」を取得する
ここで初めて OAuth らしい処理が出てきます。
「トークンサーバーからアクセストークンを取得します」
アクセストークンとは？
- 有効期限つきの デジタルな鍵
- パスワードの代わりに使う
- 漏れても期限が切れたら使えない
作業としては以下のようなイメージです。
- ログイン → その場限りの 入館証 をもらう
- その入館証で SMTP サーバーに入る
ステップ4：SMTP で OAuth を使って送信する（XOAUTH2）
いよいよメール送信です。
接続先（固定）
- サーバー：smtp.office365.com
- ポート：587
- 暗号化：STARTTLS
OAuth を SMTP に渡す方法
SMTP では XOAUTH2 という形式でアクセストークンを渡します。
Plain Text
base64(
"user=メールアドレス"
+ Control+A
+ "auth=Bearer アクセストークン"
+ Control+A + Control+A
)
その他の行を表示する
- Control+A は 0x01（見えない制御文字）
- パスワードは 一切使いません
これを SMTP の認証時に送ります
EntraID 管理画面で行うことは？
実際に EntraID 管理センターで行うことは以下の内容です。
- アプリ登録を作る
- API のアクセス許可で「SMTP送信（SMTP.Send）」を追加
- 管理者の同意（Admin consent）を付与
事前に知っておくこと
- SMTP AUTH で OAuth を使う場合、トークン要求時に SMTP用スコープを指定します：https://outlook.office.com/SMTP.Send
- Entra 管理センターでの権限追加は 「API のアクセス許可」→「アクセス許可の追加」 から行います。
手順1：Entra 管理センターで「アプリ登録」を作成する
- Microsoft Entra 管理センターにサインインします。
- 左メニューで Entra ID → アプリケーションの登録 → すべてのアプリケーション を開きます。
- 「新規登録」を選び、アプリを作成します。
- 名前：任意（例：SMTP-OAuth-Sender）
- アカウントの種類：組織内利用なら「この組織ディレクトリのみ」を選ぶのが一般的です。
- 登録が完了したら、概要画面の アプリケーション（クライアント）ID と ディレクトリ（テナント）ID を控えます（後でトークン取得に使います）。
手順2：API のアクセス許可に「SMTP.Send」を追加する
Entra ID → アプリケーションの登録 →（対象アプリ）→ API のアクセス許可 → アクセス許可の追加
具体的には
- 作成したアプリの左メニューで 「API のアクセス許可」 を開きます。
- 「アクセス許可の追加」 をクリックします。
- ここで 「Microsoft Graph」 ではなく、SMTP/IMAP/POP 用のスコープを使うための流れになります（最終的にトークン要求時に https://outlook.office.com/SMTP.Send を指定することが要件）
- 委任されたアクセス許可（Delegated permissions） を使うシナリオの場合、SMTP 送信のスコープとして https://outlook.office.com/SMTP.Send を要求対象に含めます。
併せて、必要なら offline_access も要求できます（refresh token を得て、期限切れ時に更新できます）
ポイント
- “SMTP.Send” は「メール送信していいよ」という許可です。
- “offline_access” は「再ログインなしでトークン更新していいよ」という許可です。
手順3：管理者の同意（Admin consent）を付与する
権限を追加しただけでは有効にならないことが多く、管理者が同意する必要があります。
権限（アクセス許可）を追加した後に同意が必要になることを説明しています。
- 「API のアクセス許可」 画面で「（テナント名）に管理者の同意を与えます」（Grant admin consent）を実行します。
- 確認ダイアログが出たら承認します。
ここまでで Entra 側の設定は完了です。
Entra 管理画面での設定が終わったら、次は開発/送信側で以下の設定をします。
- トークン取得時に https://outlook.office.com/SMTP.Send をスコープとして指定して access token を取得する
- SMTP で SASL XOAUTH2 形式にして渡す（Base64で user=...^Aauth=Bearer ...^A^A）
