メールに使用される認証のプロトコルは、言わずと知れた、SMTP(送信プロトコル)とPOP3及びIMAP(受信プロトコル)です。
しかしクライアントサイドの認証プロトコルは、スニッフィング被害(メール盗聴)に遭いやすく、被害も年々増加していることから、運用が難しくなってきました。
近年では、OAuth2.0を準拠とする認証方式の必然性が叫ばれていることから、メールプロバイダも積極的にこれを取り入れ始めている様子です。
ある日突然「メーラーがメールを受信出来なくなった」「奇妙な認証ダイアログが表示されるようになった」ということはございませんか。
これはメールプロバイダがOAuth認証に対応し始めた事から、発生している事象なのです。
OAuthとは何だろう。POP3/IMAPとの違いについて
POP3/IMAPの認証フローは、メールサーバとの認証に、ユーザIDとパスワードを利用します。
下記の図のように、データの要求に対して、サーバ側がユーザID/パスワードを求め、認証が完了したら、データを受領するという方式です。
実はこのBASIC認証は、ブルートフォースアタック(パスワード総当たり)に遭いやすい、という欠点がありました。
メールプロバイダ事業者も、この認証に「回数制限(数回間違えたら、数分間ログインできなくなる)」や「複数IPの同時ログイン禁止」などの措置をとってきましたが、アカウントの乗っ取りや盗聴の被害などが後を絶ちませんでした。
そこで、RFC6749として定義されたのが、OAuth 2.0 Authentication Frameworkでした。
直訳すると、OAuth2.0認証方式、といいますが、この方式をメールプロバイダが新たに取り入れることによって、一歩先のメールセキュリティ強化を図ることにしたのです。
具体的には、下記の図のように「認証専用のサーバを別途用意」して「トークンを、メールサーバとのやり取りに使用する」というものです。
「トークン」は、メールサーバと同様の共通鍵情報を持つことで、認証を実施するという働きをします。
この方式を採用することにより「アカウントの乗っ取り」に必要な「メールサーバとのユーザID/パスワードのやり取り」を見ることが出来なくなりました。
また「正規ユーザをも内訳を知らない、共通鍵で認証する」という方式なので、トークンが外部に漏れることにより、ユーザID/パスワードがどこかに漏れることがありません。
では、トークンが漏洩してしまったとしたら、どうでしょうか。
メールプロバイダが認証サーバで制御するトークンは、クライアントのIP情報や端末情報を組み込んだ共通鍵です。
共通鍵が漏洩してしまったとしても、OAuth認証の仕組みにより「別の端末からは、新たにトークンを作成する」事になります。
また、漏洩したトークンは、認証サーバ、クライアント、メールサーバのいずれかが破棄すると、再作成することになりますので、重大な情報が漏れる機会が少なくなります。
また、メールサーバはトークンによって認証を行いますので、ユーザIDやパスワードの変更の必要が無くなるのです。
実際にOAuth認証を実施してみた！
ここでは、Gmailを用いた「OutlookによるOAuth認証」を行う手順を解説いたします。
以下手順においては、Outlook365にてGmailアカウントへOAuth認証を実施してみました。
①Outlookの「ファイル＞情報＞アカウントの設定」へ推移し「メール」タブの新規を押下します。
②E-mailアドレス（Gmail）を入力すると必ず「問題が発生しました」通知（OAuth認証失敗）が出ますので「アカウント設定変更」へ推移します。
③アカウントの設定画面で「接続」ボタンを押下すると、別ウインドウ（ブラウザ）にてGmail認証画面へ推移し、対応するアカウントとパスワードを求められます。
そのほか、認証先E-mailボックスへの通知であったり、携帯電話への認証コード通知であったり、様々なアプローチ方法があります。
④ログインに成功すると、Googleからの「アクセス許可」確認が行われます。
「許可」すると「アカウントが正常に追加」通知が出ますので、これで認証完了です。
以上のように、ユーザサイドからすると「認証アカウントや端末等」さえ用意しておけば、OAuth認証は、さほど難しくありません。
あとは運用管理者が「認証アカウントや端末等」をいかに用意するか？が課題となるようです。
主要メールプロバイダのOAuth認証対応状況
主要であるメールプロバイダは数知れずではありますが、OAuth認証を率先して導入し、そちらを主要な認証として取り込み済みのプロバイダもあります。
エンドユーザである、メーラーとそのクライアントは、認証方法がワンテンポ必要になるだけで良いのですが、企業の運用管理者はひとたまりもありません。
OAuth認証を今後の運用とする代わりに、エンドユーザ向けのPOP3/IMAPによる認証を廃してしまうためです。
そのため、企業の運用管理者は、OAuth認証用に携帯端末などを導入したり、ファイアウォールの接続受け入れをしたりなどをしたり、運用管理に応じて、様々な準備が必要です。
下記、主要メールプロバイダのPOP3/IMAP廃止状況となります。
<Apple : iCloud – 2020年6月30日終了>
https://developer.apple.com/news/?id=03262020b
各主要メールプロバイダともに、これまでコロナ渦の影響から、この期限を延長しておりましたが、次々とPOP3/IMAP認証を廃止しているようです。
<Microsoft : Exchange – 2020年10月13日終了>
https://docs.microsoft.com/ja-jp/lifecycle/announcements/exchange-online-basic-auth-deprecated
Microsoft Echangeも2020年10月で終了となりました。
Exchangeは企業利用がかなり多いので、そのハレーションも凄まじいのではないでしょうか。
<Google : Gmail – 無期限延長中>
https://gsuiteupdates.googleblog.com/2020/03/less-secure-app-turn-off-suspended.html
Gmailは無期限に延長してくれているようですが、実質、個人利用のGmailに関しては移行が終了している状況です。
法人向けのG Suiteに関しても、時間の問題のようです。
取り上げた3社ともに、Webブラウザからの閲覧に対応しておりますので、最悪は、Webブラウザ上からアプローチしていく形となりそうです。
しかしながら、メーラーのOAuth認証対応状況や、OAuth認証のアプローチ方法など、前もって、把握しておくべきなのかもしれませんね。
