OAuth2でメール接続
セキュリティ向上のため、多要素や人の手による随時操作を前提としたリアルタイムな評価ポリシーの採用が広がっています。
Microsoft社の Exchange Online でも基本認証が廃止されました。
サービス利用にMFAやOAuth2が求められる一方、自動実行されるような任意アプリからもサービスを利用したいことは多いのではないでしょうか。
そこで、アプリからOAuth2を使う際のイメージを書いてみました。
まずOAuth2は、ユーザーが、第三者アプリへ、IDやパスワード(資格情報)を渡さずに、サービス(リソース)へのアクセスを許可する仕組みです。
OAuth2は、4つのロール、アクセストークンで許可(認可)を与える方法を中心とした仕様です。ユーザにとって第三者のクライアントは、アクセストークンを用い保護リソースに対し許可されたアクセスを行うことができます。
どこかでログイン(ユーザー認証)したユーザー(リソースオーナー)は、自身のID等を渡していない第三者サービスとも連携でき、OAuth認証と言われたりしますが、OAuth自体は認可の仕様で、認証方法は範囲外です。
OAuthは認可を与える主体の①誰を、認証することも要すので、これらは混同されることもありますが、仕組み上は、
OAuth2はユースケースに応じ、有効期限が異なるコードやトークン類を使い分けセキュリティを担保する形で、幾つかの処理フローが用意されており、
認可取得後は、更新トークンフローを用い長期間、人の手を介さずサービスを利用することもできます。(各フローの説明はやや複雑で多くなるのでここでは触れません)
MicrosoftのExchange Onlineへ接続するには、OAuth2でアクセス許可を得るためAzureアプリの登録をします。
Azureアプリ登録のエンドポイントを経由して、外部のWebアプリ上にあるメールクライアントからもExchange Onlineへ接続することができます。
まずOAuth2認可コードフローを用い、アクセストークンを取得しますが、その際Entra ID認証ページ入力操作だけは残念ながら人の手で行います。
OAuth2認可で、アプリ(クライアント)が取得したアクセストークンは
「①認証されたユーザーが、
②第三者のWebアプリ(のメールクライアント)に、
③メールアクセス(IMAPやPOP,SMTPによる接続)を、
④認可している」
ということを、チケットの様にサーバー側へ示すことが出来る情報で、
メールサーバーへはIMAP等既存プロトコルで、このアクセストークン送付によるBearer認証を(ユーザー,パスワード認証代わりに)行なって接続します。
アクセストークンは数時間で有効期限が切れますが、数十日単位と期限が長い更新トークンで再発行し(更新トークンフロー)、Exchange Onlineでは90日間ユーザー操作を要さず自動で処理を行えます。
OAuth2でメールを使う場合も、認可の仕組みとしてロールがどの様に実装と関連し何が行われるか、アプリ利用時はあまり意識しないかもしれませんが、構築時はそれら役割の概要やイメージが役に立つかもしれません。
この記事が気に入ったらサポートをしてみませんか？