はじめに
Microsoft 365(Exchange Online)では、SMTP Auth(ユーザー名＋パスワードによる基本認証)の廃止が進んでおり、OAuth(先進認証)への切り替えが事実上必須になっています。
「そもそもOAuthって何？」「SMTP Authと何が違うの？」というところを自分なりに整理したので共有します。SMTP送信をOAuth化する具体的な設定手順(アプリ登録〜アクセストークン取得〜XOAUTH2でのSMTP送信まで)は元記事で詳しく解説していますので、実装まで踏み込みたい方はそちらもどうぞ。
元記事: [【Microsoft365参考書】OAuth とは？OAuth と SMTP Auth の違いとは？]
OAuthは「認証」ではなく「認可」の仕組み
まず押さえておきたいのは、OAuthはユーザー本人を確認する**Authentication(認証)ではなく、「このアプリに、この範囲のことを、いつまでやっていいか」を委任するAuthorization(認可)**の仕組みだという点です。
パスワードそのものをアプリに渡すのではなく、Entra ID(旧Azure AD)が発行した有効期限つきのアクセストークンをアプリが使ってAPIやSMTPサーバーにアクセスします。パスワードを預からない分、漏洩時の被害範囲を抑えられる設計になっています。
SMTP Authとの違い
比較するとシンプルです。
| 項目 | SMTP Auth(Basic) | OAuth |
|---|---|---|
| 認証情報 | ユーザー名＋パスワード | 期限付きアクセストークン |
| MFA対応 | 基本的に不可 | 対応可能 |
| 権限の粒度 | アカウント全権限 | スコープ単位(例:メール送信のみ) |
| Microsoftの方針 | 廃止方向 | 標準・推奨 |
SMTP Authはパスワードさえ割れれば実質フルアクセスされてしまう一方、OAuthは「メール送信だけ」のように必要最小限の権限(スコープ) を渡せて、しかもトークンが短命なので、漏洩時のリスクがかなり違います。パスワードスプレー攻撃などレガシープロトコル特有の攻撃に弱いことが、基本認証廃止の背景にあるようです。
OAuthの2大フロー
用途によって使うフローが変わります。
- Authorization Code Flow(ユーザーあり): ユーザーがサインイン・同意した上で、そのユーザーの代わりにアプリが動く「委任」型。メールクライアントなど一般的な業務アプリ向け。
- Client Credentials Flow(ユーザーなし): アプリ自身が管理者から信頼された権限を持つ「アプリ権限」型。ユーザーの同意画面は挟まず、バッチ処理や自動送信サービスなど、サーバー間通信で使われます。
この他に、CLIツールなど入力操作に制約がある環境向けの「デバイス認可付与フロー」もあり、実質は認証コードフローの派生という位置づけです。
SMTP送信をOAuth化する大まかな流れ
詳細手順は元記事に譲りますが、全体像としては次の3ステップです。
- Entra管理センターでアプリ登録を行う(このアプリがEntra IDと連携する「名札」を得る)
- SMTP.Sendのスコープを付与し、管理者同意(Admin consent)を行う
- トークンを取得し、SMTP送信時にXOAUTH2形式(Base64エンコードしたユーザー名＋Bearerトークン)で認証する
アプリ登録・スコープ付与・管理者同意という3点セットは、Exchange Online管理者であれば一度は通る作業なので、事前に流れを把握しておくと実装時に迷いにくいと思います。
おわりに
基本認証の廃止スケジュールが進む中で、「なぜOAuthが安全なのか」「SMTP Authと何が違うのか」を理解しておくと、移行対応の説明や設計判断がしやすくなります。Entra管理センターでの具体的な画面操作や、アプリ登録からXOAUTH2での送信までの詳しい手順は元記事にまとめていますので、実装を控えている方はぜひ参考にしてください。