大川氏は、「Azure ADを介することで、Microsoft 356が保有しているID情報を使って、さまざまなアプリケーションの認証を行うことが可能になります。アプリケーション開発者にとっては、ユーザー管理や認証設計が不要となるため、業務ロジックの開発に専念できます。一方で、その認証フローは非常に複雑で、トラブル時にハマりやすい箇所でもあります」と指摘する。

　Azure ADは、どのようなフローで認証を行っているのだろうか。まず、大川氏は、Azure ADの設定のポイントについて紹介した。

　Azure ADには認証エンドポイントとして、「Azure AD v1」と「Azure AD v2」の2つのバージョンがある。v1はAzure ADベースで、組織アカウントのみをサポートする。v2はMicrosoft IDプラットフォームベースで、組織や個人、B2Cアカウントをサポートする。

　大川氏は「ここで注意してほしいのが、v1は非推奨であるという点です。v2の認証エンドポイントを使用するのが基本です」とアドバイスする。

　認証プラットフォームとしては、WebアプリやSPA（シングルページアプリケーション）、モバイルアプリ、Windowsデスクトップアプリをサポートする。特に、SPAでは、認可コードの横取り攻撃を防止する「PKCE」（Proof Key for Code Exchange by OAuth Public Clients）に対応している。

　APIのアクセス許可を取る場合には、Azure ADを介してアクセスできるリソースを設定しておき、ログインやトークン要求時に「スコープ」でこのリソースを指定する。これによって、ユーザーは、Graphリソースや他のAzure ADで保護されたアプリケーションにアクセスできるようになるという。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

（出典：SlideShareで公開の資料より）

　Azure ADの設定後、認証エラーが発生した際の対処法として、「認証エラーが発生した場合には、エラーのコードとそれに関わるドキュメントのリンクが記載されたエラーメッセージが表示されます。細かくエラーの内容を返してくれるので、このメッセージをしっかり見れば解決することが多い」とアドバイスした。

Azure ADの3つの認証フローと使い分け、適した利用ケース

　ここまでのAzure ADの認証設定を踏まえた上で、大川氏は、実際にAzure ADで認証を行う際の認証フローの種類とその使い分け、適した利用ケースについて解説した。

　Azure ADを使った認証フローの種類は、「OAuth/Open ID Connect」「資格情報」「On-Behalf-Of」の大きく3つに分けられるという。

「OAuth/Open ID Connect」

　Microsoft 365のユーザーIDとパスワードを使用して、保護されたリソースにアクセスする時に使う基本的な認証だ。認証フローは、ユーザーが認可されたWebアプリにログインする際に、Microsoft 365のユーザーIDとパスワードを入力する。OAuth 2.0オーサライズエンドポイントでその情報が一致した場合、OAuth 2.0トークンエンドポイントにリクエストが出され、アクセストークンが返却される。このアクセストークンを使うことで、Azure ADで保護されたWebAPIにアクセスできる。

　「『OAuth/Open ID Connect』の認証フローでは、ユーザー自身がMicrosoft 365のID情報を入力してアクセストークンを取得し、ログインします。そのため、シークレット認証などを用意する必要はなく、クライアントIDのみで認証が可能です。主にMicrosoft 365のユーザーにひも付いた情報を取得したい場合には、この認証が適しています。一方で、全ユーザーのイベント情報を閲覧できるといったGraphリソースの強力な権限を取得する場合にはおすすめできません」としている。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

（出典：SlideShareで公開の資料より）

「資格情報」

　Microsoft 365のユーザーIDやパスワードを入力せず、Azure ADアプリケーションで発行したシークレットを使用する認証だ。具体的な認証フローは、OAuth 2.0オーサライズエンドポイントを介さずに、Azure ADのクライアントシークレットを使って、ダイレクトにOAuth 2.0トークンエンドポイントにリクエストを行う。ここで取得したアクセストークンを使うことで、Azure ADで保護されたWebAPIへアクセスが可能になる。

　「『資格情報』での認証は、どちらかというとバックエンドのWebAPIやAzure Functionsでの認証が必要な際に適しています。ユーザーによるID情報の入力は不要となり、『アプリケーションのアクセス許可扱い』となります。例えば、Azure ADのメールやイベント情報の全閲覧権限の取得など、ユーザーを介さずに比較的強力な権限が必要な場合に、この認証フローが使われます」とのことだ。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

（出典：SlideShareで公開の資料より）

「On-Behalf-Of」

　WebAPIから別のWebAPIを呼び出す場合に使用する認証だ。具体的な認証フローは、まずMicrosoft 365のユーザーID／パスワードを使ってAzure ADで保護されたWebAPIにログインする。次に、そのWebAPIから、Microsoft IDプラットフォームに対して、GraphのWebAPIを呼び出すためのトークンをリクエストし、返却されたアクセストークンを使うことで、Graphリソースにアクセスすることが可能となる。

　「Azure ADを使った認証の中でも、特にややこしいのが『On-Behalf-Of』で、WebAPIアクセス時のアクセストークン情報を引き回したい時に使われます。例えば、自社開発のWebAPIにログインし、その中でGraphのWebAPIにアクセスして、ユーザーにひも付くデータを引っ張ってくるといった場合にはこの認証が適しています。最初にログインしたユーザーのID情報が最後まで引き継がれるため、ユーザーにひも付いた情報をGraphから簡単に取得できます。なお、この認証フローでは、Graphへのアクセストークン生成時に、アクセス元のAzure ADで再認証が行われるため、シークレットが必要不可欠になります」と説明した。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

（出典：SlideShareで公開の資料より）

ややこしい認証フローを助けてくれる2つのライブラリ

　そして、「こうした認証フローの複雑な処理をサポートしてくれるのがライブラリの存在だ」と大川氏は訴える。「Azure ADの認証フローは、ややこしいことに加えて、stateやPKCEのチャレンジトークンなど、セキュリティ標準を満たすためのさまざまなルールが存在します。さらに、リダイレクトなども含むため、素でやろうとすると処理が非常に複雑になります。ライブラリは、これらの要件を満たす処理をよしなにしてくれます」（大川氏）

　今回のセッションでは、代表的なJavaScriptのライブラリとして、「adal.js」と「msal.js」が紹介された。

　「『adal.js』は、Azure AD v1.0認証エンドポイント用のライブラリです。v1.0が非推奨のため、現在はメンテナンスモードでの開発になっています。また、単独でnpmで公開されていないため、昨今の開発では少し使いづらく感じます。昔作ったWebAPIがv1.0エンドポイントで公開されているなど、特殊な状況で使われるライブラリです」とのことだ。

　「一方の『msal.js』は、Microsoft IDプロバイダーによる認証の基本ライブラリです。『msal.js』のv2からは、PKCE対応されており、SPAプラットフォームでも利用できます。また、npmで公開されているため気軽に使用することができ、AngularやReactなどフレームワーク用のライブラリも用意されています」と、実質的な標準ライブラリである「msal.js」を活用することを推奨した。

　最後に大川氏は、「Azure ADによる認証は、便利に使える一方で、認証フローが複雑でややこしいという難点があります。しかし、この認証フローを理解しておくことでトラブルシュートがやりやすくなるので、ぜひ押さえておいてください。また、認証フローの開発には、基本ライブラリの『msal.js』を活用し、3種類の認証を用途に応じて正しく使い分けるのがポイントです」とまとめた。