MENU

メール認証の必須課題。OAuth認証の仕組みと今後の動向

メールに使用される認証のプロトコルは、言わずと知れた、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認証のアプローチ方法など、前もって、把握しておくべきなのかもしれませんね。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

管理人のよしぞと申します。
フリーランス業界で働いている管理人が、業界で働く様々な視点からフリーランスエンジニアに挑戦するためのノウハウを掲載。独立を考えている方にとって手助けになるサイトを目指しています。

目次