id:kizashi1122 です。
弊社が開発・運営している Re:lation でも遅ればせながら Exchange Online の先進認証に対応しました。 Microsoft が 2020/10/13 にExchange Online の基本認証を廃止するというアナウンスをしたためです。
このエントリでは以下のような流れで説明を進めます。
基本認証と先進認証
Microsoft のドキュメントを見ると基本認証は英語で Basic Authentication であり、先進認証は Modern Authentication であることがわかります。。
基本認証と言っていますがいわゆるHTTP上のBASIC認証のことではありません。
ユーザ名とパスワードを使った認証のことを指しています。 つまり今までは、SMTP/POP3/IMAP を利用する際に、Office365 のユーザIDとパスワードを使う必要がありました。しかしセキュリティ上好ましくないとのことで、この基本認証が廃止になり、先進認証に置き換わることになりました。
ちなみに「廃止」と書きましたが、コロナの影響によりこの基本認証を利用していたアカウントについては、2021年の後半までは使えるようです。
そして先進認証ですが、これはいわゆる OAuth 2.0 を指しています。
SMTP/POP3/IMAP を利用する際に、ユーザ名とパスワードではなく、ユーザ名と OAuth 2.0 で取得したアクセストークンを使って認証することになります。
やること
さて先進認証の対応と一言で言っても、やるべきことはたくさんあります。
- OAuth 2.0 の設定（Azure AD側）
- OAuth 2.0 の設定（サービス側）
- アクセストークンをつかった SMTP/POP3 の認証
- リフレッシュトークンを使ったアクセストークンの更新
細かいことは他にもありますがおおまかに言うとこんな感じになるでしょうか。 実はこの先進認証対応についてですが、 Re:lation では G Suite については対応済でした。このときは技術的な部分ではなく、Google とのやりとりでかなり苦戦しました。そのあたりのことはすでにこちらに記載しています。
Gmail API（Google OAuth）利用承認取得記 - 思ったより大変でした - インゲージ開発者ブログ
この G Suite での経験もあり、今回の Exchange Online での対応はさくっと終わると予想していましたが、その読みは甘く G Suite とは別の意味で苦戦しました。 その苦戦した内容を何回かにエントリをわけて解説していきたいと思います。
本エントリでは「OAuth 2.0 の設定（Azure AD側）」まで書こうと思います。
用語の整理
Azure AD の画面では「アプリ」という言葉が出てきます。
当然「アプリケーション」の略ですが、アプリケーションというとサービス側と勘違いしてしまいそうにもなるのでここで用語の整理をしておきたいと思います。 OAuth まわりでは、きちんとした定義はあるかと思いますが、このエントリでは以下のように定義し以降はこの用語を使います。
| 一般化した場合 | Re:lationの場合 | |
|---|---|---|
| サービス利用者 | リソースオーナー | ユーザ |
| アクセストークン発行側 | 認可サーバ | Office 365 |
| アクセストークン利用側 | サービス | Re:lation |
OAuth 2.0 の設定（Azure AD側）
前提として、Azure AD にアカウントを作っておく必要があります。 弊社では Office 365 のアカウントをすでに持っていたので同じアカウントでログインできました。
アプリの登録
次に、Azure AD の管理画面からアプリの登録をします。アプリという言葉を使っていますがあくまで Azure AD で作る設定となります。
[新規登録] よりアプリを作成します。
リダイレクトURIの設定
アプリに関する情報を登録します。名前は何でもいいです。何でもいいですが、この名称は認可画面で表示されることにご注意ください。
ここですね。
次に、 リダイレクト URI を登録します。これはいわゆるコールバックURLのことです。
OAuth で認可画面でユーザIDとパスワードを入力後に戻るリダイレクト先（サービス側）のURLとなります。
リダイレクト URI は開発環境では http://localhost を使うことができます。
それ以外では https である必要があります。
認可サーバーによっては、開発環境用でも https を利用が必須の場合があるので、Office365 はその意味では楽でした。
Re:lation ではユーザはマルチテナント型のサービスのためそれぞれ固有のサブドメインを持つという特有の事情があります。
そのため、リダイレクト URI は全ユーザ共通のURLを発行する必要があり、その共通URLに遷移後、各自のサブドメイン側のURLにリダイレクトする仕組みを自作しています。
シークレットトークンの発行
証明書とシークレット メニューをクリックしましょう。
シークレットトークンの発行は、私の知る限り、認可サーバ側で設定を新規作成した時点で発行されてることが多いと思うのですが、Azure AD では明示的に発行する必要があります。期限は選べますが「なし」を選んでおけばよいでしょう。「なし」を選んだとしても有効期限はちゃんと設定されるようで 2299/12/31 となるようです。
↓
通常、シークレットトークンはクライアントIDとペアで使います。そのクライアントIDはどこにあるのでしょうか？
こちらは 概要 メニューのところにあります。
スコープの設定
あとはスコープの設定です。何の権限を与えるか？という話です。
APIのアクセス許可 メニューをクリックします。
User.Read はデフォルトで選択されています。
ここでは SMTP と POP3 を使った送受信をユーザの代わりにサービスがおこないたいという要件になります。
アクセス許可の追加 から Microsoft Graph を選択し、
- offline_access
- SMTP.Send
- POP.AccessAsUser.All
を選択して保存します。
選択後はこのような画面となります。
画面にある API/アクセス許可の名前 はサービス側からも設定する必要があり、その場合は scope というパラメータに設定することになります。
Teams と連携したい場合は Teams を選択すればよいと思いますし、ここはやりたいことによってアクセス許可の内容も変わってきます。
おさらい
サービス側では設定に必要になるのは
- クライアントID
- シークレットトークン
- スコープ（画面では
API/アクセス許可の名前）
になります。
あとは簡単じゃない？と思いたいですが、スコープでハマることになります。
が、今回はここまで。
続きはこちら。
