はじめに

Azure AD B2Cを利用することが増えてきたので、App ServiceのEasy Auth「認証と権限承認」と絡めて利用できないか。せっかくなのでマルチリージョン対応を見据えてAzure Front Doorをフロント配置する構成で検証しました。

App Serviceの作成

App Serviceを作成します。この部分は今回は割愛します。
リソースの名前は「azureadb2ceasyauth」とします。

Azure AD B2Cで認証機能を利用するためには、以下、２つの方式があります。

今回は、既に用意されているテンプレートを利用する「ユーザーフロー」を利用します。
※ 基本的にはユーザーフローで事が足りるはずですが、「ユーザーフロー」では実現できないことを「カスタムポリシー」で実現すると捉えて頂ければと。

以下の手順に従って、Azure AD B2Cを構築します。

こちらは「B2C テナントの作成」に従ってテナントを作成する。

ユーザーフローの作成に従って作成する。ただし、今回はEasy Authを検証したいので、ユーザーフローとしては、「サインアップとサインイン (推奨)」を利用して作成します。

この時Web AppsのEasy Authで利用するURLとして、必要になるため、「ユーザーフローを実行します」で表示されるURLをコピーしておきます。

ルール：https://{B2Cテナント名}.b2clogin.com/{B2Cドメイン}/v2.0/.well-known/openid-configuration?p={ユーザーフロー}

作成したApp Serviceの「認証/承認」でEasy Authを設定します。

ここがポイントで、Front Doorを利用してEasy Authをする場合は、一度App ServiceにFront Doorに利用するカスタムドメインを適用し、その後、Front Doorを向くようにDNSを再度変更する必要がある。

これをしないと、認証情報入力後のリダイレクトURLが合わずにFrontDoor経由ではなく、App Serviceに直接リダイレクトされてしまい、Front Doorの価値がなくなってしまいます。

カスタムドメイン設定後、「認証/承認」の「許可される外部リダイレクト URL」に以下を入力する。

ここまで来たら、Front Doorのドメインとバックエンドプール、ルーティングルールを設定することで、無事Easy Authが利用できます。