buchizoちょっと必要に駆られたのでメモ書きです。ADやTwitterなどのソーシャル系のみです。Appsと裏側のAPIとなるFunctionsをそれぞれ保護するためのTipsを纏めておきます。想定環境としては以下のような感じ。AppsとFunctionsのEasyAuthを構成します。Appsで提供されるWebアプリはJavaScriptとかで直接Functionsに通信するけどその際に本人のアクセストークンを使わないとAPIが呼べないようにしたい、というのが主旨ですね。B2C側で最低限の設定を行います。Framework(IEF)の作成アプリケーションの登録の大きく2つです。要件によってユーザーフローかIEFでカスタムポリシーを作ります。IDプロバイダーの追加やユーザーの作成などは適宜どうぞ。B2Cのユーザーフローは最低限サインアップ/サインインフローがあればとりあえずEasyAuthは構成できます。Webアプリ用とBackendのFunctions用に2つ登録します。この時の注意点は2つほど。付与したURLにすること、2つ目はアプリケーション登録(プレビューじゃないほう)で作るアプリキー(Secret)は期限が100年というところでしょうか。Serviceでカスタムドメインを指定していない場合は以下のようになります。name>.azurewebsites.net/.auth/login/aad/callbackそれぞれ作ってアプリケーションIDとアプリキーを控えておきます。(EasyAuth構成時に使用します)EasyAuthの構成EasyAuthの構成(Web/Functionsとも)はそんなに難しくありません。罠があるのでその辺は後程。Directoryを選んでAdvancedを選択し、必要な情報を設定していきます。B2Cの対象のユーザーフローのopenid-configurationを指定します。このURLはユーザーフローの実行時に表示される値をコピーすれば楽です。name>という形式のURLなので分かってしまえばどうということはないです。(ユーザーフローを指定するのを忘れずに)さてこれでWeb/Functionsは適切なアクセストークンなりが無いとアクセスできないように保護されました。めでたしめでたし...と言いたいところですがこのままでは思ったことはできません。B2CでログインしてID_Tokenを取得したりはできます)具体的にはWebでログインした際にAccess_Tokenが含まれてないのでAPI(Functions)を呼ぶ際に困る、Refresh_Tokenもないというところでしょうか。いうことで次はそのあたりを構成します。B2C(IdP)側は提供してくれません。B2Cテナントに登録したアプリケーションに情報を追加します。B2C側で最初にBackend(Functions)用として登録したアプリケーションを「アプリの登録(プレビュー)」のほうで表示します。「APIの公開」でスコープを追加しましょう。スコープ(アプリケーションIDのURL+スコープ名なURL)は後で使うので控えておきます。これでバックエンド側にはこんなスコープがありますよというのが定義できました。次にFrontend(Web)側のアプリの登録(プレビュー)でそのAPIを使うようにアクセス許可を行います。アクセス許可の追加を行い自組織内からBackend用のアプリを選べば先ほど追加したスコープが出てくると思うので追加して管理者の同意を与えます(管理者アカウントで同意をしておかないとアクセス時に利用者に同意を求めてくる(と思う)、が権限が無いのでエラーになる)。最終的に状態が「<テナント名>に付与されました」になればOKです。次はWebアプリ側です。Webアプリにアクセスがあって認証する際に、BackendのAPI(リソース)に対するトークンもくださいと指示する必要があります。B2Cのエンドポイントを叩いたりする場合はOIDCなどのお作法に従えばいいのですがEasyAuthで行う場合はちょっとコツが必要になります。構成する必要があります。Explorer」から開けます)このプロパティは認証時に渡すいろんなパラメーターを指定できます。今回修正が必要なのはresponse_typeとresource、scopeの3つになります。Backendアプリに登録したスコープ(URL)を指定します。https://xxxx.onmicrosoft.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/user_impersonation"]余談ですがこのauthsettingsを追加すればEasyAuthの構成ができるので自動展開する際は参考にしましょう。以上で構成は終了です。アクセスするとaccess_tokenやrefresh_tokenが含まれていることがかります。あとはWebアプリ内でこのaccess_tokenをBearerトークンとしてAuthorizationヘッダーに付与すればFunctionsのAPIでも問題なくアクセスできます。Functions側でもEasyAuthを構成してますので、アクセストークンの検証は自動的にしてくれますし、TokenStoreやHTTPリクエストヘッダー経由で必要な情報を取得し、適切に処理することができるようになります。最低限の構成はこれでOKですが、Webアプリ側やバックエンドのAPI側ではスコープを見てアクセスの可否を判断したり、アクセストークンの管理や更新、サインアウトなど適切に処理するようにちゃんと開発しましょうね。サインアウト時のページなど一部URLはEasyAuthで認証必須にしたくない(匿名でもOK)といった要件は以下のリンクにあるようにアプリルートにauthorization.json(またはYaml)を置いてルールを構成すれば対応可能です。RulesというわけでEasyAuthは(ちょっと闇が多いけど)非常に便利で素晴らしい機能だと思うのでうまく活用しましょう。コメントをキャンセルコメントを入力してください。以下に詳細を記入するか、アイコンをクリックしてログインしてください。アカウントを使ってコメントしています。アカウントを使ってコメントしています。アカウントを使ってコメントしています。アカウントを使ってコメントしています。新しいコメントがついたらメールで通知。免責事項このBlogおよびコミュニティにおける発言やコメントは、当方の所属する会社・団体の正式な見解またはコメントではありません。Blog.%d人のブロガーが「いいね」をつけました。