先進認証（モダン認証）とは？基本認証との違いとメール送信での対応方法を解説
Microsoft 365やGoogle Workspaceをはじめとするクラウドサービスでは、セキュリティ強化を目的として、従来の「基本認証（レガシー認証）」から「先進認証（モダン認証）」への移行が急速に進んでいます。とくにExchange OnlineではSMTP AUTH（基本認証）の廃止が段階的に進められており、「気づいたらメールが送れなくなっていた」というトラブルも起こり得る状況です。
しかし、「先進認証と基本認証は何が違うのか」「OAuth 2.0やトークンとは具体的に何を指すのか」「複合機や業務システムからのメール送信はどう対応すればよいのか」といった疑問を整理できていない方も多いのではないでしょうか。
本記事では、先進認証（モダン認証）の仕組みと基本認証との違いを整理したうえで、OAuth 2.0の認証フローやメール送信で用いられるXOAUTH2の仕組み、そして先進認証への具体的な移行手順までを、システム担当者・エンジニアの視点で網羅的に解説します。読み終えるころには、自社の環境で「何を確認し、どう対応すべきか」の判断軸が得られるはずです。
目次
先進認証（モダン認証）とは
先進認証（モダン認証）とは、クラウドサービスなどへのアクセスをより安全に管理するための認証方式の総称です。英語では「Modern Authentication」と表記されます。
最大の特徴は、パスワードそのものをサービスへ送信するのではなく、権限が制限された「トークン」を用いてアクセスを制御する点にあります。これにより、認証情報の漏えいによる不正アクセスのリスクを抑えつつ、多要素認証（MFA）や条件付きアクセスといった高度なセキュリティ機能と組み合わせられるようになります。
先進認証は単一のプロトコルを指す言葉ではなく、OAuth 2.0・SAML・OIDC（OpenID Connect）といった複数の認証・認可技術を包括した概念です。メール送信やクラウドサービスへのアクセスの文脈では、主にOAuth 2.0が用いられます。
先進認証が生まれた背景
従来の基本認証は「ユーザーIDとパスワードをそのまま送る」というシンプルな方式であり、長年にわたって幅広い環境で利用されてきました。しかし、フィッシングやパスワードリスト攻撃といった手法の高度化により、ID・パスワードだけでは十分なセキュリティを確保できなくなっています。
一度パスワードが漏えいすれば、第三者がどこからでもログインできてしまう。この構造的な弱点を克服するために登場したのが先進認証です。パスワードを直接やり取りせず、利用状況やデバイス情報などの文脈（コンテキスト）も踏まえて多層的にアクセスを制御することで、なりすましや不正利用を防ぎやすくします。
Microsoftは、こうした背景からExchange Onlineの基本認証を順次廃止し、先進認証への移行を強く推奨しています。これは一企業の方針にとどまらず、クラウドとゼロトラストの普及に対応するための業界全体の流れといえます。
OAuth 2.0によるトークンベースの認証
先進認証の中核を担うのがOAuth 2.0です。OAuth 2.0は、本人確認を行う「認証（Authentication）」そのものではなく、ユーザーやアプリに対してサービスを利用する権限を与える「認可（Authorization）」のためのフレームワークで、RFC 6749で標準化されています。
OAuth 2.0では、ユーザー認証と同意が完了すると、クライアントアプリに「アクセストークン」が発行されます。アプリはサービスへアクセスする際、ユーザーのパスワードではなく、このアクセストークンを提示します。サービス側はトークンに紐づく権限の範囲や有効期限を確認したうえで、利用を許可する仕組みです。
つまり、アプリはパスワードを一切保持・送信せず、期限付き・権限限定の「通行証」だけを扱います。仮にトークンが漏えいしても、有効期限が切れれば使えなくなり、権限の範囲も限定されているため、パスワードが漏れる場合と比べて被害を最小限に抑えられます。
多要素認証（MFA）・条件付きアクセスとの組み合わせ
先進認証の強みは、単体のトークン認証にとどまりません。トークンを発行する前段の「本人確認」の部分に、多要素認証（MFA）や条件付きアクセスを組み合わせられる点が本質的な価値です。
多要素認証は、パスワード（知識情報）に加えて、スマートフォンのアプリ（所持情報）や生体認証（生体情報）など、異なる種類の要素を2つ以上組み合わせて本人確認を行う仕組みです。条件付きアクセスは、アクセス元のIPアドレス・端末・時間帯などの条件に応じてアクセスの可否を制御します。
これらと組み合わせることで、「正規のパスワードを知っているだけ」の第三者を排除でき、基本認証単体では実現できないレベルのセキュリティを構築できます。
基本認証（レガシー認証）とは
基本認証（レガシー認証）とは、先進認証が普及する以前から利用されてきた従来の認証方式です。設定が比較的容易で、多くのアプリや機器・システムで採用されてきました。「レガシー（旧式の）認証」とも呼ばれます。
ID・パスワードによる認証の仕組み
基本認証では、アプリがサービスへ接続する際に、ユーザーIDとパスワードをそのまま送信します。サービス側は受け取った情報が正しいかを検証し、認証に成功した場合にアクセスを許可します。
メール送信においては、メールソフトや業務システム、複合機などにユーザーIDとパスワードを設定し、SMTPサーバーへ接続する方法が長く使われてきました。この手軽さが普及の理由であり、いまも多くの機器が基本認証を前提に動作しています。
基本認証が抱えるセキュリティリスク
基本認証の最大の課題は、アプリがユーザーのパスワードを直接扱う点にあります。認証情報が漏えいすれば、第三者にそのまま不正利用されるおそれがあります。パスワード自体には「どこまでの操作を許可するか」「いつまで有効か」といった制限を設ける仕組みがないため、一度漏れると被害が広範囲に及びやすいのです。
さらに、基本認証は多要素認証との相性が悪く、MFAを回避する経路として悪用されるケースも指摘されてきました。攻撃者が基本認証エンドポイントを狙うことで、MFAを設定していても突破されてしまう——こうしたリスクが、基本認証廃止の大きな動機となっています。
先進認証と基本認証の違い
先進認証と基本認証の主な違いを整理すると、以下の通りです。
| 比較項目 | 先進認証（モダン認証） | 基本認証（レガシー認証） |
|---|---|---|
| アクセスに使用する情報 | アクセストークン | ユーザーID・パスワード |
| パスワードの取り扱い | アプリがパスワードを直接送信しない | アプリがパスワードを直接送信する |
| MFA・条件付きアクセス | 組み合わせて利用できる | 対応できない場合が多い |
| アクセス権限の制御 | トークンごとに権限範囲・有効期限を設定可能 | 権限範囲を限定する仕組みがない |
| 漏えい時のリスク | 有効期限・権限で被害を限定しやすい | 第三者に不正利用されやすい |
| 導入・対応のしやすさ | アプリ・サービス側の対応が必要 | 対応機器が多く導入しやすい |
ポイントは、セキュリティの高さと導入のしやすさがトレードオフの関係にあることです。先進認証は安全性で優れる一方、接続元のアプリやシステムがOAuth 2.0に対応している必要があります。既存の業務システムや複合機などでは対応が難しい場合もあり、現実の運用では、セキュリティ要件とシステムの対応状況の両面から認証方式を選ぶことが重要になります。
OAuth 2.0の認証フローと登場人物
先進認証を正しく理解するには、OAuth 2.0が「誰と誰の間で、何をやり取りしているのか」を押さえることが近道です。ここでは認証フローの内側を具体的に解説します。
認証を構成する4つの役割
OAuth 2.0の認可フローには、主に次の4つの登場人物（ロール）が存在します。
- リソースオーナー: データや機能の持ち主。多くの場合、サービスを利用するユーザー本人を指す
- クライアント: ユーザーの代わりにリソースへアクセスするアプリケーション（メールソフトや業務システムなど）
- 認可サーバー: ユーザー認証と同意を経て、アクセストークンを発行するサーバー
- リソースサーバー: 実際のデータや機能を保持し、トークンを検証してアクセスを許可するサーバー（メールサーバーなど）
典型的な流れは次のようになります。まずクライアントがユーザーを認可サーバーへ誘導し、ユーザーがログインと権限の同意を行う。すると認可サーバーが「認可コード」を発行し、クライアントはそれをアクセストークンと交換する。以降、クライアントはアクセストークンを提示してリソースサーバーへアクセスします。この一連の流れは「認可コードグラント」と呼ばれ、もっとも標準的なパターンです。
アクセストークンとリフレッシュトークンの違い
OAuth 2.0で扱うトークンには、性質の異なる2種類があります。この違いを理解しておくと、実際の運用でつまずきにくくなります。
- アクセストークン: リソースへアクセスするための短命なトークン。有効期限は数十分〜数時間程度と短く設定されることが多い
- リフレッシュトークン: アクセストークンの有効期限が切れた際に、ユーザーの再ログインなしで新しいアクセストークンを取得するための長命なトークン
リフレッシュトークンを取得するには、認可時にoffline_accessのようなスコープ（権限）を指定する必要があります。これを忘れると、アクセストークンの期限が切れるたびにユーザーの再認証が必要になり、無人で動く業務システムやバッチ処理では運用が破綻してしまいます。
システムからの自動送信を継続させたい場合は、「リフレッシュトークンを安全に保管し、期限内に自動でアクセストークンを更新し続ける」仕組みの設計が欠かせません。ここが、無人運用における先進認証対応の最大の勘所です。
メール送信における先進認証（SMTP AUTHとOAuth 2.0）
ここまではクラウドサービス全般の話でしたが、メール送信の現場でも先進認証への移行が進んでいます。もっとも影響が大きいのが、Exchange OnlineにおけるSMTP AUTHの廃止です。
SMTP AUTHとは
SMTP AUTHは、IDとパスワードを使う基本認証の一種で、メールソフトや業務システムなどのSMTPクライアントが、SMTPサーバーへメール送信を依頼する際に認証を行う仕組みです。クライアントが認証情報を提示し、サーバーがそれを検証したうえでメール送信を許可します。
SMTP AUTHは幅広い環境で利用でき、多くのメールソフト・業務システム・複合機・監視ツールが対応しているため、既存システムからメールを送信する用途で広く普及してきました。だからこそ、この方式が廃止されると影響範囲が非常に大きくなります。
XOAUTH2によるメール送信の仕組み
メール送信でOAuth 2.0を利用する場合、「SASL XOAUTH2」というメカニズムが使われます。これは、IMAP・POP・SMTPの各コマンドでOAuth 2.0のアクセストークンを用いて認証するための方式です。
XOAUTH2では、ユーザー名とアクセストークンを特定の形式で結合し、Base64エンコードした文字列をサーバーへ送信します。具体的なフォーマットは以下の通りです。
base64("user=" + ユーザー名 + "^Aauth=Bearer " + アクセストークン + "^A^A")ここで^AはControl-A（制御文字0x01）を表します。SMTPクライアントは、従来のAUTH LOGINの代わりにAUTH XOAUTH2コマンドと、この形式で組み立てた文字列を送信することで、パスワードを送らずに認証を完了できます。
つまり、メール送信でOAuth 2.0に対応するとは、「SMTPクライアント側がアクセストークンを取得し、XOAUTH2形式で送信する処理を実装する」ことにほかなりません。古い機器や自作システムでは、この処理を後付けで実装するハードルが高いという課題があります。
Exchange OnlineのSMTP AUTH廃止スケジュール
Microsoftは2026年1月27日に公開した公式ブログで、Exchange OnlineにおけるSMTP AUTH（基本認証）の廃止スケジュールを更新しました。
これによると、2026年12月以降に作成される新規テナントではSMTP AUTHの基本認証が既定で無効となり、サポートされる認証方式はOAuthのみとなる見込みです。既存テナントについても、2026年12月以降は基本認証の初期値が無効化される方針が示されています。最終的な完全削除の時期は、2027年後半に改めて発表される予定とされています。
ただし、このスケジュールは過去に複数回見直されており、今後も変更される可能性があります。必ずMicrosoftの公式情報で最新のスケジュールを確認してください。 廃止後にSMTP AUTHで送信を試みると認証エラーとなり、メールが送信できなくなります。とくに複合機のスキャンtoメール機能、業務システムからの自動通知メール、旧バージョンのメールクライアントなどが影響を受けやすいため、早めの棚卸しが重要です。
なお、Exchange OnlineのSMTP AUTH廃止の詳細や具体的な影響については、以下の記事で詳しく解説しています。
先進認証への移行手順と注意点
「移行が必要なのは分かったが、何から手をつければよいのか」。ここでは、先進認証への移行を進める実務的なステップと、対応が難しいシステムへの現実的な対処法を解説します。
移行前に確認すべきチェックリスト
移行を成功させる鍵は、闇雲に対応を始めるのではなく、まず現状を正確に把握することです。以下の項目を洗い出しましょう。
- STEP 1：送信元の棚卸し: どの機器・システム・アプリがExchange Online経由でメールを送信しているかをすべてリストアップする
- STEP 2：認証方式の確認: 各送信元が基本認証（SMTP AUTH）を使っているか、OAuth 2.0に対応済みかを確認する
- STEP 3：対応可否の判定: OAuth 2.0対応のファームウェア更新やバージョンアップが提供されているかをメーカー・ベンダーに確認する
- STEP 4：移行方式の決定: 送信元ごとに「OAuth対応へ移行」「代替手段へ切り替え」のいずれかを決める
- STEP 5：期限からの逆算: 廃止スケジュールから逆算し、検証期間を含めた移行計画を立てる
とくに見落とされがちなのが、普段は意識しない複合機や監視ツール、古い基幹システムからの通知メールです。これらは動いていて当たり前になっているため棚卸しから漏れやすく、廃止当日に突然メールが止まって初めて気づく、という事態になりかねません。
OAuth 2.0対応が難しいシステムへの対処法
現実には、すべての送信元をOAuth 2.0へ移行できるとは限りません。メーカーサポートが終了した複合機や、改修コストの見合わない古い業務システムなど、「OAuth対応が困難な送信元」は必ず残ります。
こうしたケースでの代表的な選択肢を比較すると、以下の通りです。
| 対応方法 | 概要 | 向いているケース | 留意点 |
|---|---|---|---|
| OAuth 2.0対応へ移行 | 送信元をXOAUTH2対応にアップデート・改修する | メーカーが対応版を提供している機器 | 対応版がない古い機器では不可 |
| Microsoft Graph APIへ移行 | Graph APIの/sendMailで送信する方式に作り替える | 自社開発でソース改修が可能なシステム | 開発工数が大きい |
| メールリレー／配信サービス経由 | 送信先をリレーサービスに変更し配信を中継させる | 改修困難な複合機・業務システム | サービスの選定・設定が必要 |
なかでも、改修が難しい既存システムに対して有効なのが、外部のSMTPリレー・メール配信サービスを経由させる方法です。送信元のシステムはこれまで通りSMTPでメールを送り、その宛先をメール配信サービスに向けるだけ。実際のインターネットへの送信や認証まわりの運用は配信サービス側が担うため、送信元システムを一切改修せずにメール配信を継続できます。
先進認証への対応に頭を悩ませている送信元がある場合、この「中継させる」というアプローチは、コストと安全性のバランスに優れた現実解になります。
メール送信の認証方式に迷ったらメール配信サービスを活用する
基本認証の廃止は、単なる設定変更の問題ではなく「自社で認証・配信インフラを維持し続けるか、専門サービスに任せるか」という選択でもあります。OAuth 2.0対応の実装やトークンの運用、送信ドメイン認証の設定までを自前で抱えるのは負担が大きく、ここでメール配信サービスの活用が有力な選択肢になります。
メール配信システムを使うメリット
メール配信サービスを利用すると、認証や到達率まわりの複雑な運用をまとめて外部に委ねられます。とくにSMTP AUTH廃止への対応という文脈では、次のようなメリットがあります。
- 既存システムを改修せずに配信を継続できる: SMTPリレーで送信先を切り替えるだけで対応可能
- 認証・到達率の運用を任せられる: SPF/DKIM/DMARCなどの送信ドメイン認証やIPレピュテーション管理を専門サービスが担う
- エラー対応や監視の負荷を軽減できる: バウンス処理や配信ログの管理を自動化できる
自社でメールサーバーや認証基盤を維持し続けるコストと比べれば、専門サービスへの移行はむしろ運用をシンプルにする一手になります。
おすすめのメール配信システム「blastengine」
blastengine（ブラストエンジン）は、お客様のシステムとSMTPリレーやAPIで連携することで、既存システムからのメール送信を簡単に実現できる開発者向けのメール配信サービスです。SMTP AUTHの廃止で送信経路の見直しを迫られている場合でも、送信先をblastengineに向けるだけで、既存システムを改修せずにメール配信を継続できます。
- API連携・SMTPリレー: 既存システムへの組み込みが容易で、設定変更のみで最短当日から利用開始できる
- 99%以上の高いメール到達率: 国内キャリア・ISPへの個別送信ロジックと高いIPレピュテーション管理で確実に届ける
- SPF/DKIM/DMARC対応: 最新のメール認証技術に標準対応し、なりすまし・迷惑メール判定を回避
- バウンスメール自動対応・配信ログ管理: エラーメール管理を自動化し、運用負荷を大幅に削減
- 業界最安クラスの料金: 初期費用無料、月額3,000円〜で大量配信も低コストで実現
複合機や業務システムなど、OAuth 2.0対応が難しい送信元からのメール送信をまとめて引き受け、面倒なサーバー運用や認証対応からエンジニアを解放します。メールアドレスの入力のみで無料トライアルが可能ですので、まずは気軽にお試しください。
ブラストエンジン公式サイト：https://blastengine.jp/
まとめ：先進認証への移行は「送信元の棚卸し」から始める
本記事では、先進認証（モダン認証）の仕組みと基本認証との違い、OAuth 2.0の認証フロー、メール送信で用いられるXOAUTH2の仕組み、そして先進認証への移行手順までを解説しました。
先進認証は、パスワードを直接扱わず、権限と有効期限が設定されたアクセストークンを用いる認証方式です。多要素認証や条件付きアクセスと組み合わせることで、基本認証と比べて不正アクセスのリスクを大きく抑えられます。一方で、接続元のシステムがOAuth 2.0に対応している必要があり、複合機や古い業務システムでは対応が難しいケースも少なくありません。
まず取り組むべきは、Exchange Onlineなどからメールを送信している送信元の棚卸しと、それぞれの認証方式の確認です。そのうえで、OAuth 2.0対応への移行が難しい送信元については、SMTPリレー・メール配信サービスを経由させる方法を検討しましょう。廃止スケジュールから逆算し、検証期間に余裕を持って計画を立てることが、メールが止まるリスクを避ける最善の対策です。
FAQ
- 先進認証と多要素認証（MFA）は何が違いますか？
- A：先進認証は、トークンを用いた認証・認可の仕組み全体を指す包括的な概念です。多要素認証（MFA）は、その中で「本人確認をより厳格に行う」ための一要素にあたります。先進認証の基盤の上でMFAを組み合わせることで、より高いセキュリティを実現できます。
- 基本認証（SMTP AUTH）はいつ使えなくなりますか？
- A：Microsoftの2026年1月27日の公式発表では、2026年12月以降にSMTP AUTHの基本認証が既定で無効化され、最終的な完全削除の時期は2027年後半に発表される予定とされています。ただしスケジュールは変更される可能性があるため、必ずMicrosoftの公式情報で最新の状況を確認してください。
- OAuth 2.0に対応できない複合機や業務システムはどうすればよいですか？
- A：主な選択肢は、対応版ファームウェアへの更新、Microsoft Graph APIへの作り替え、そしてSMTPリレー・メール配信サービスの経由の3つです。改修が難しい古い機器やシステムでは、送信先を配信サービスに向けるだけで対応できるSMTPリレーの活用が現実的です。
- 先進認証に切り替えれば必ず安全になりますか？
- A：先進認証は基本認証よりも安全性が高い方式ですが、それ単体で万全になるわけではありません。多要素認証や条件付きアクセスと組み合わせ、送信ドメイン認証（SPF/DKIM/DMARC）やTLSによる通信の暗号化なども併せて実施することで、はじめて堅牢なメール送信環境を構築できます。
- メール送信でOAuth 2.0を使うには何が必要ですか？
- A：送信元のSMTPクライアントがXOAUTH2メカニズムに対応し、アクセストークンの取得と自動更新（リフレッシュトークンの運用）を行える必要があります。無人で動く業務システムでは、トークンを安全に保管し期限内に更新し続ける仕組みの設計が欠かせません。
