Azure AD B2CをPHPと使う (5) SharePointリストに接続するには・・
Azure AD B2C は、SharePoint 外部パートナー共有のシナリオには適していません。
これは、FAQに書いてある内容なのですが、すなわち、Azure AD B2Cによる承認フローを用いて、Azure AD B2Cをホストしている組織のSharePointへの承認は得られないことを指します。
そこで、サーバーを経由して解決します。
前記事に書いた内容は、実はこのことが念頭にあったためです。
具体的には、SPA上でAzure AD B2Cで認証し、Webサーバー等にリクエストを送り、そこでAzure AD B2Cの承認内容を確認して、SharePointサーバーに対する適切な権限を解釈して、Graph APIで処理を行うという流れになります。
サーバーで動作させるのは、無論、PHPである必要はありません。
以上、現場からお伝えしました。
雑感
SharePointはAzure ADで管理する、といいますか、Azureの中の人に聞いた話では、Azure ADは、AzureチームではなくてOffice365チームが管理しているという密接な関係にあります。
であれば、Azure AD B2CでSharePointに接続できてもよいよね？というのが自然な流れかと思います。
この違いについては、こちらの記事がよくまとまっているので参照しておきます。
この中で、
もし、あなたが自社組織の ID を管理しようとしており、その管理のための機能が必要な場合、Azure AD B2C は適切なソリューションではない可能性があります。つまり、求める機能は Azure AD B2C では実現できない、あるいは自身で細かい実装が必要になる可能性がありますのでご注意ください。
これがまさに今回のケースですね。
Azure AD B2CをPHPと使う (4) Client Credentials Grant Flow (サーバープロセスとしてGraph APIを使う)
Auth0ではなく、Azure AD B2Cを使う理由の一つに、Microsoftのサービスとの連携があります。
たとえば、SharePointリストは非常に安価ながら大量のデータを保存できるリスト型DBとして使用できます。
もし、SharePointリストで業務データを管理しているとしたら、いつ仕様が変更されるともわからないSharePointアドオンを開発するよりも、独立したWebサイトでアプリケーションを組むほうが学習コストが低い場合があります。また、SharePointに限らず、Outlookなどを業務で使用している場合なども同様でしょう。
Webアプリケーションである場合には、Azure ADのロールで管理すれば十分でそのアプリケーションを使っている人から委任を受けてアプリケーションがGraphAPIにアクセスすることになるでしょう。
これが、Authorization Code Grant Flowです。
ユーザーの代わりにアクセスを取得する - Microsoft Graph | Microsoft Docs
ところでSharePointのリストの中には、管理者のみがアクセスしたいデータがある場合があります。ここで使用するのが、元は、Client Credentials Grant Flowと言われる方法ですが、現在は、事前に管理者の委任を受けたコードを保存しておく、と言った方がよいかもしれません。
たとえば、Firebaseのデータを定期的にSharePointにポストするといったタスクは、ユーザーの手を介さずに実行したいですね。
このドキュメントのタイトルが微妙で、いつも検索にかからないので、メモしておきます。
PHPからのGraphAPIの呼び出しについては、Authorization Code Grant Flowを少し変更した程度になりますので、以下のチュートリアルが参考になると思います。
Microsoft Graph を使って PHP アプリを構築する - Microsoft Graph | Microsoft Docs
Azure AD B2Cを始める(5) vs Firebase Authentication
vs Auth0
Azure AD B2CとAuth0を比較するとき、印象としてはAuth0の方が的確な実装を行うなどフラットにプロダクトを評価すればAuth0に軍配が上がる気がします。
それでも私がAzure AD B2Cを選択する理由は、業務用システムなどでOffice365認証が基礎にありこの信頼度が高い事が挙げられます。つまり、私のビジネス上の理由として、Windowsのデスクトップ環境とシームレスに認証でき、なおかつクライアントの招待などを統合しつつ安全に運用するのに適しているから、というのがあります。
もし、純粋にWebサービスに専心するプロジェクトであれば、Azure AD B2CよりもAuth0の方が第一選択になるような気がします。
vs Firebase Authentication
このことは、Firebase Authenticationとの比較でもいえます。
Webアプリケーション実装は結局のところデータベースとの接続の問題はついて回りますが、データベースサーバーを安定稼働させるには、複数のデータベースサーバー間のレプリケーション等の運用管理、モバイルデバイスなどオフライン時の更新データの同期の問題など悩ましい問題は多くあります。
この点、認証と同期というWebアプリケーションの最も面倒な部分をFirebaseは解決して提供してくれています。しかも、低負荷であれば無料。
たとえ社内に大規模なRDBMSがあったとしても、WebアプリケーションではFirebaseを使うメリットがあると感じられます。
（RDBMSとの連携機能を追加するコストを払ってでもメリットがあるのではないか。）
連携か択一か
当然ですが、認証情報が二元化するなんて、ありえないですよね。
こっちのWebアプリはAzure AD B2Cで、Firebaseに書き込む時だけFirebase Authenticationを使うとか。
Azure AD B2CもFirebase Authenticationも複数のSSOに対応していますが、両方にgithubアカウントでサインインしているのにUX上は独立・・・
そう、ありえない。
そうすると、
- Firebase Authenticationを使わず、FirebaseのサービスでAzure AD B2Cアカウントに対する承認ができるようにする。
- Firebase Authenticationで、Azure AD B2Cとの間のフェデレーションを組む
いずれかを実現していくことになりそうです。
Azure AD B2CをPHPと使う (4) JWT検証について
サーバー側はAPI実装に専念し、APIではトークンの検証を行います。
Azure AD B2CをPHPと使う (2) SPAから送られてきたトークンを検証する - noopableの日記 (hatenablog.jp)
という記事を先日書きましたが、現在のところJWTの検証が中心課題となります。
総合雑感
認証用のサービスとしても、提供されているSDKの品質でもAuth0が先行している感じですね。
個人的には、firebase/jwtがよいかなと思っています。
JWT検証の仕組みなど
まずは、こちらの記事がわかりやすいです。
Get Started with JSON Web Tokens - Auth0
日本語ではこちらでどうでしょう。
JSON Web Tokens - jwt.io で、具体的に、エンコード、デコードを試すことができます。実装中にデバッグするときなど便利ですね。
これを基本として、
JWT検証について考えるべきこと
Auth0さんで、セキュリティ上の問題などを指摘していただいています。
いろいろと参考になります。自分で実装する場合やライブラリの検証を行う際には注意してみたいと思います。
この記事で、
これだけのベスト プラクティスに対応するのは荷が重すぎると思われる場合は、一部作業を外部プロバイダーに委託するのも一案です。その際にはぜひ Auth0 の利用をご検討ください。外部に委託できない場合は、この記事で挙げた推奨事項について入念に検討しましょう。そして、暗号化の方法は決して自作せず、テストを重ねた実績あるコードを利用するようにしてください。
まったく賛成で、Auth0かAzure AD B2Cを候補に考えています。
それでもサーバー側の実装については知識や経験を持っていることが求められると思います。たとえば、上記のページに出ている攻撃パターンなどについてチェックすることはもちろん、安全側に振ったチェックも必要ですし、仮に後述するfirebase/php-jwtを使うとしても、現行サービスで利用していないアルゴリズムは検証する前に弾くとか、オプションのclaimでも追加でチェックするといった形で手堅くいきたいですね。
JWT用のPHPライブラリの一覧など
こちらのサイトでは登録されたライブラリがトークンのチェックなどにどのように対応しているのかが示されているようです。
結構たくさんありますね。
いくつか見てみましたが、これが究極的にシンプル！
luciferous/jwt: PEAR package for JWT (github.com)
JWTクラスだけが定義してあります。
こういった、濁りのない基底クラスをキッチリ作って始めていく習慣が必要だと思います。他のフレームワーク用のライブラリなどではフレームワークと密結合してしまい流用できないものが多く悲しくなります。
最も基本的なクラスだけでは仕事にならないので、上をフォークしたFirebaseプロジェクトのphp-jwtを見てみます。
これいいですね。テストもわかりやすく、安心感があります。
ライセンスはBSD v3。
他にめぼしいところというと、これからな。
nowakowskir/php-jwt: JSON Web Tokens (JWT) implementation for PHP 7. (github.com)
PHP7用となっていますが、中身はシンプルで必要なものが揃っている感じはします。
JWT用のAuth0用ライブラリなど
そのAuth0がPHP用のライブラリを公開していることは有名かもしれません。
Auth0 PHP API SDK Quickstarts: Authentication
基本通りに書かれていて、他のフレームワーク等で流用しやすくなっています。MITライセンスですし、Auth0だけではなく、Azure AD B2Cで使用する際にも、微調整で対応できるかもしれません。
クラス構成で考えると、これも有力
lcobucci/jwt: A simple library to work with JSON Web Token and JSON Web Signature (github.com)
Symfony界隈はどうなのか。
本格的にSymfonyを使っているわけではないので、他によいソリューションがあるのかもしれませんが、
lexik/LexikJWTAuthenticationBundle: JWT authentication for your Symfony REST API (github.com)
このバンドルが使われているケースが多いでしょうか。
Symfony用のバンドルですから、フレームワーク用のファイルが増えるのはやむを得ないと思いますが、他のフレームワークや素のPHPで使いやすいかというと、全く使えないです。クラス構成など、正規化されていないDBを見るようで憂鬱です。これがSymfonyバンドルの標準なのでしょうか・・・
Securing Symfony API with JWT | OAuth and OpenID Connect Done Better (curity.io)
これならむしろ、Azure AD B2C用の古いサンプルがLaravel用で公開されていましたが、そちらに軍配を上げる感じ。
Introduction - JWT Framework (spomky-labs.com)
web-token/jwt-framework: JWT Framework (github.com)
その名もJWT Framework。Symfony Insight シルバーメダルがついています。
JWS (RFC 7515)、JWE (RFC 7516)、JWK (RFC 7517)、JWT (RFC 7519)などにも対応しているようです。
Azure AD B2C でSPA (3) サンプル実行マラソン
複数のコードサンプルを、複数のパターンで試す
プロダクトを理解するには、READMEおよびコードリーディングが早いです。
しかし、手を動かして初めてわかる知見もありますね。というわけで、いくつかのサンプルを試してみました。
結果をまとめると、Azure AD B2CのAzure Portalでの設定項目とMSAL.jsのインスタンスを作成する際のmsalConfigの関係、動作フローなどの理解が進みました。
adal.jsのときのような実行した段階での不安定さなどもなく、多少の調整をすれば全般に簡単に動きます。安心できる品質になっていると思います。
以後のメモになりますが、
- Azure Portalで設定を完了したらユーザーフローをAzure Portalから実行してAzure AD B2C側の問題をすべて解決しておく
- SPAの場合、Azure PortalにアプリケーションのURLをSPAのURLとして追加する。
- Microsoftアカウント、GoogleアカウントなどのIdpを追加する場合には、WebのリダイレクトURLとして追加する。
- 今回のサンプルではオープンなCORSが設定してあるが、自分の環境では適切に準備する。
その他にも、注意すべき点などはあると思われます。たとえば、サンプルではルートページにSPAが展開され、Azure AD B2Cなどすべてのredirect_urlは同一でした。
しかし、実際のUXでは、ユーザーはあるページのSPA下から同一ドメインの他のページでもサインイン状態を継続したいというのが普通かと思います。また、別のタブを開いた時などにもその状態の維持を望むでしょう。cacheLocationをlocalStorageにすれば解決する問題も、今度は逆にセキュリティ上の問題を生じてしまうリスクを考慮しなければならないでしょう。
以前のadal.jsでは一部のedgeやI.E.で無限ループが生じるという問題が発生することがありました。それも「常に」「すべてのブラウザーで」というわけではないため問題の特定が難しい状況にありました。こういった問題はプロダクトを選択するにあたっては大きな地雷になりうるのでプロダクト選択段階であぶり出しておく必要があると思います。
本稿の目次
- 複数のコードサンプルを、複数のパターンで試す
- SPA開発にはAPIモックが必要 (JSON-SERVER)
- Azure-SamplesのAPIモック
- サンプル(1) Single-Page Application built on MSAL.js with Azure AD B2C
- 自テナントでの実行結果【サンプル(1)】
- サンプル(2) JavaScript Single-page Application secured with MSAL.js using the Authorization Code Flow (PKCE) on Azure AD B2C
- サンプル(3) Angular 11 MSAL Angular 2.x B2C Sample
- サンプル(4) MSAL.js 2.x Sample - Authorization Code Flow in Single-Page Applications
SPA開発にはAPIモックが必要 (JSON-SERVER)
サンプルの中には、APIのモックを稼働していただいているものもあります。
しかし、せっかくなので自前でモックを作っておく方が何かと確認しやすいはず。
今回は、簡易的なものとしてJSON Server、時間があればPHPでトークン検証を含めたモックを作成したいとおもいます。
npm install -g json-server
json-server -p 3200 --watch db.json
こんな感じですかね。
これでlocalhost:3200にアクセスするとjson-serverの説明が出て、db.jsonに格納したリストへのアクセス方法など簡単な説明がでればOK.
検証よりもAPIまでリクエストが到達したというチェックだけでよい場合には簡単です。
Azure-SamplesのAPIモック
いくつかのサンプルで利用されるAPIのモックの構築手順がAzure-Samplesで提示されています。
node.jsとpassport.jsで構築するようです。
こちらの手順通りに、git clone、npm install、npm startの3ステップ。
config.jsonで、テナント名やclientID policyName scopeなどを編集しました。
サンプル(1) Single-Page Application built on MSAL.js with Azure AD B2C
最初のMSAL.jsを使ったSPAサンプルといえると思います。
手順通りに進め、Microsoftアカウント(個人用)でサインインできました。
サインインした情報がAPI経由で取得できることも確認できました。
テストした後は、
https://account.live.com/consent/Manage
にアクセスして、アクセス許可を削除しておきます。
（次回のサインアップテストができるようにするためにも）
これで、正常に登録されたアプリであれば、このサンプルが動作することはわかりましたので、次は、自前のテナントと先ほど作ったAPIで実行できるかどうかを確かめます。
自テナントでの試行【サンプル(1)】
b2cScopesの構成
自テナントのアプリケーションでb2cScopesを定義します。
Azure Portalの[管理] の [API の公開]で、アプリケーション ID の URIは、テナントURLの後は、テナントIDが入っていると思いますが、これは自分で識別できればapiなどとしてよいようです。転記ミスのないようにシンプルな方がいいでしょう。
次に、同様にAPIへのアクセス許可も与えておきます。
この手順はアプリケーションを登録した時、APIを登録した時に行えばよいので、私はつい忘れがちです。
ポリシーの構成
対応するポリシー（ユーザーフロー）をまだ作っていなければ、作って設定します。
テナントIDの構成
authConfig.jsに登録したアプリのアプリケーションID(クライアントID)を転記
CORSの構成
先ほどのAzure-SamplesのAPIモックでは、最初からCORS設定済みのようです。
自テナントでの実行結果【サンプル(1)】
前提として、サンプルを試す前に自テナント内でユーザーフローを実行してhttps://jwt.msで受信して確認しておくというのはやっておきます。
それでREADMEの通りにやってみたのですが、やはり手を動かしておく意味はありますね。
サインインの画面まではいくのに、その後のアクションが起きません。
B2Cのユーザーフローには入っており、consoleログを見ると、id_tokenも取れている。
それでauthRedirect.jsをチェックしたのですが、claimとしてacrをチェックしています。ところが、B2Cからのトークンにacrは含まれていないようなのです。
トークンの概要 - Azure Active Directory B2C | Microsoft Docs
acrのチェックは使用したユーザーフローのチェック、つまりユーザーの意図をチェックするものと言えますので、これをtfpに変えてみたところ、無事サインインまでできたようです。
で、チェックしてから検索したところ、stackoverflowさんに出てますね。acrとtfpの切り替えができるそうです。ユーザーフロー毎のプロパティ設定のようですが、パスワードリセットの際は、acrでないとダメ？なのかもしれません。
これで、Azure AD B2Cに登録したユーザーIDでの認証とAPI呼び出しはうまくいきました。
また、Microsoftアカウントで認証すると例外が発生しました。
ServerError: AADB2C90273: An invalid response was received : 'Error: invalid_request,Error Description: Proof Key for Code Exchange is required for cross-origin authorization code redemption.'
PKCEの設定ができていないように思います。実は、acr関係のトラブルに対処するのに、基本の設定からいろいろと変えて試しているうちに迷走してしまったようです。Microsoft用アカウントのリダイレクト先をWebからSPAに変えてしまったためのようです。ドキュメントではWebとして登録すると書いてあったのですが、今回のサンプルがSPAであったため、acrが原因ではなく、そこかな？と思い変更していたのでした。
他にもどの設定を間違えるとどんなエラーになるのかというのは一通り経験しておくというのもいいと思います。エラーログを見ているうちに、どの設定がどこで使われているのかが体感できます。
詳しくはログの確認なども必要かもしれません。
MSAL アプリでのログ記録 - Microsoft identity platform | Microsoft Docs
サンプル(2) JavaScript Single-page Application secured with MSAL.js using the Authorization Code Flow (PKCE) on Azure AD B2C
次のサンプルは、Azure AD B2CにMSAL.js v2でアクセスします。いわゆる、承認コードフローです。
インストールしてnpm startするだけで、問題なく動作しました。
自テナントでの実行結果【サンプル(2)】
自テナントに加え、APIは先ほどの例と同様のモックを使います。
編集するファイルも先ほどのものと同様のようです。
いずれも問題なく動作しました。
無事動作してしまうと、あまり収穫がないですが、とりあえず問題なさそうです。
Azure Blobへのディプロイ
このサンプルのREADMEにはAzure Blobへのディプロイについて説明があります。
今のところ、私はAzure Storageを使う予定はないので割愛します。
（後日テストしたら更新したいと思います。）
サンプル(3) Angular 11 MSAL Angular 2.x B2C Sample
こちらは、MSAL.js v2とAngular 11を使ったサンプルです。本稿時点では最新の環境と思われます。githubの更新も頻繁に行われていますね。
$ git clone git@github.com:AzureAD/microsoft-authentication-library-for-js.git
$ cd microsoft-authentication-library-for-js/samples/msal-angular-v2-samples/angular11-b2c-sample/
事前準備：
https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-angular
msal-angularのREADMEに沿って準備をしておきます。
npm install @azure/msal-browser @azure/msal-angular@alpha
テストを実行する場合には、
npm run build
npm run test
とするところでしょうか。
事前準備が終わったらnpm startしてみます。
問題なく動作しますね。外見上はAngularであるかどうか気付く要素もないですが（）
consoleにaccess_tokenやid_tokenが出るようになっているようです。
自テナントでの実行結果【サンプル(3)】
READMEでは、b2c-config.tsとapp.module.tsを編集しろとありますが、おそらく、app.componet.spec.tsについても編集する必要がありそうです。
また、本sampleの実行URLをB2C側のリダイレクトURLとして追加します。
これで、動きました。
α版とはいえAngular の11で何事もなく動作しましたので、今後も期待したいと思います。
サンプル(4) MSAL.js 2.x Sample - Authorization Code Flow in Single-Page Applications
上記のリポジトリにはMSAL.jsの複数のサンプルがあり、すべてを試す必要はなさそうです。
ここでは、最もシンプルであろうMSAL.js 2.xとVanilla.jsのサンプルを試します。
まず、samples/msal-browser-samples/VanillaJSTestApp2.0/ に移動して、READMEを確認。
npm install @azure/msal-browserで実行するだけでは、うまくいきません。
このサンプルを確認すると、どうもローカルのlibを必要としているように見えます。おそらく、自分でビルドしたものを試したいときにはその方がよいという意図でしょう。今回はもう少し軽い使い方でindex.htmlでcdnを参照するように変更、server.jsも書き換えてindex.htmlはサンプルフォルダのものを実行するようにしてみます。
//res.sendFile(path.join(__dirname + '/index.html'));
res.sendFile(path.join(APP_DIR + '/index.html'));
そして、npm start
無事動きました。
今回はMicrosoft Graphへのアクセスですし、エンドポイントが
https://login.windows-ppe.net/common/
だったのですが、Office365 Enterpriseのエンドポイントなんでしょうか。
Azure AD B2C でSPA (2) MSAL.js
MSAL.jsへ移行する
以前にAzure AD B2Cでリリースした際は、adal.jsというライブラリを使用していました。2020年6月頃より、Microsoftとしては、adal.jsではなく、MSAL.jsの使用を推奨しています。
Azure AD B2Cを用いると、認証フローなどのシナリオについては、ほぼ自動化されているので、SPA開発には、概ね MSAL.jsの使い方を理解すればよいということになります。
ソースツリーでlibを見ると、いくつかのパッケージがあります。
- msal-angular
- msal-angularjs
- msal-browser
- msal-common
- msal-core
- msal-node
- msal-react
この構成図も置いてあります。
WebアプリケーションとしてのSPAを実装するのにあたっては、msal-browserで実装するかAngularまたはreact用のラッパーを利用することになりそうです。
msal-reactは1.4.1のリリースブランチにはなく、devにありましたので、これから、といったところでしょうか。
各lib（ラッパー) について REAMEより
- msal-core
OAuth 2.0 暗黙的承認フローのコアライブラリ - msal-browser
OAuth 2.0 PKCE承認コードフロー - msal-angular
msal-browserのAngular用ラッパー - msal-react
msal-browserのReact用ラッパー
バージョンの違い
前記事で、公式サンプルは2つあると書きましたが、MSAL.jsのバージョンの違いが大きかったと思います。
バージョンの違いは、
暗黙的な許可フローをサポートする MSAL.js 1.0
PKCE での承認コード フローをサポートする MSAL.js 2.0
とのことです。
また、
現在の OAuth 2.0 のベスト プラクティスでは、SPA に対して、暗黙的なフローではなく承認コード フローを使用することを推奨しています。 また、有効期間が制限された更新トークンを使用することも、Safari ITP のような最新のブラウザーの Cookie プライバシー制限にアプリケーションを適合させるのに役立ちます。
とのことなので、支障がなければ、2.0系にしておく方がよさそうです。
その支障は？というと、PKCEフローを実装できるか、かもしれません。
もう一つ気になる情報といいますか、MSAL.js 2.0のREADMEによると、
Important: MSAL.js 2.0 with Authorization Code Flow is not yet available for B2C tenants (coming soon).
は？もうすぐですと？
現状でも2.0用のサンプルは上がってるのですが、承認コードフローにはなっていないということなんでしょうか・・・注意深く試していこうと思います。
MSAL.jsのPKCE での承認コード フローを理解する
MSAL.js 2.0のフローを理解するのに適したチュートリアルがあります。
本チュートリアルでは、Graph APIを読んでいますが、プロジェクト毎に必要なAPIにで構築するのは容易でしょう。
ユーザーが初めて [Sign In] ボタンを選択すると、signIn メソッドによって、ユーザーがサインインするための loginPopup が呼び出されます。 loginPopup メソッドによって、"Microsoft ID プラットフォーム エンドポイント" でポップアップ ウィンドウが開き、ユーザーの資格情報が要求されて検証が行われます。 サインインに成功すると、msal.js によって 認証コード フローが開始されます。
この時点で、PKCE で保護された認証コードが CORS によって保護されたトークン エンドポイントに送信され、トークンと交換されます。 アプリケーションによって ID トークン、アクセス トークン、および更新トークンが受信され、msal.js によって処理されて、トークンに含まれる情報がキャッシュされます。
ID トークンには、表示名など、ユーザーについての基本的な情報が含まれています。 ID トークンによって提供されるデータを使用する予定がある場合は、アプリケーションの有効なユーザーに対してトークンが発行されたことを保証するために、バックエンド サーバーはトークンを検証する "必要があります"。
アクセス トークンの有効期間は限られており、24 時間後に有効期限が切れます。 更新トークンは、新しいアクセス トークンを自動的に取得するために使用できます。
このチュートリアルで作成した SPA は、acquireTokenSilent、acquireTokenPopup、またはその両方を呼び出して、Microsoft Graph API に対するユーザー プロファイル情報の照会に使用される "アクセス トークン" を取得します。 ID トークンを検証するサンプルが必要な場合は、GitHub の active-directory-javascript-singlepageapp-dotnet-webapi-v2 サンプル アプリケーションを参照してください。 このサンプルでは、トークンの検証に ASP.NET Web API を使用しています。
実際のコードとしては、libのmsal-browserを見ることになります。
msal-browserのREADMEは、丁寧に書かれているので、何ができるのかも確認しやすいのではないかと思います。
それで、2.0系の理解には、msal-browserを理解すればよいということになります。
実際、msal-browserのREADMEが充実しているように思いますので、
ここから行ってみよう！！
Azure AD B2C でSPA (1) サンプルをチェックする
現在、PHPでAPIを構成し、SPA上で認証を経たトークンでアクセスするという計画で動いています。
公式ドキュメントでAzure AD B2CのSPAのサンプルを見ると以下の２つがリンクされています。
ほとんど同じじゃないか！という気がしなくもないですが、コードを見るとMSAL.jsで取得しているアプリケーションの種類が違うようです。
そこで、少し調べてみたのですが、
前者は、
const myMSALObj = new msal.PublicClientApplication(msalConfig);
後者は、
const myMSALObj = new Msal.UserAgentApplication(msalConfig);
msal.jsには2バージョンあり、publicとprivateを切り分けるようになったのはv2と思われます。つまり、前者のリンクはmsal.jsのv2ベースで、後者のリンクはmsal.jsのv1ベースということでしょうか。
いずれにしても、MSAL.jsで、トークンの取得や更新をやってくれるので、この部分を任せられるのはありがたいところ。
今回は、前者の方を中心に検討していきたいと思います。
そして、その先の認証周りのシナリオについてはAzure AD B2Cに任せます。
つまり、アプリケーション側は、入り口まで誘導し、結果を受け取るだけでよいということになります。
