Azure Static Web Apps のプレビュー環境は、GitHub を利用した開発中に Pull Request を作成したタイミングで自動的にデプロイされるので、変更点の動作確認やレビューが行いやすくなる便利な機能なのですが、カスタム認証を使ったアプリケーションでは利用が難しいものでした。
カスタム認証を使うとプレビュー環境を使うのが難しい理由は、URL が別で発行されるので OpenID Connect のようにコールバック URL を登録する必要がある場合に、何らかの方法で登録する必要があるためです。
以下のドキュメントでも Microsoft Entra ID を使った認証では、/.auth/login/aad/callback というパスの絶対 URL を Entra ID 側に登録する必要があると記載されています。
実際に Entra ID でのログインを Static Web Apps に組み込む際には、Entra ID アプリケーション側で以下のように Static Web Apps へのコールバック URL を登録する必要があります。
Static Web Apps の本番向け URL はリソースを再作成しない限り固定されるので、シンプルに設定できます。
本番向けだけであれば、後は staticwebapp.config.json に必要な設定を追加すれば、Entra ID を使ったログインを実装出来ます。画像だと説明が難しいですが、Entra ID を使ったログインを問題なく行えています。
この状態で Pull Request などをトリガーに作成されるプレビュー環境を使って試してみます。プレビュー環境の URL は Pull Request の場合は ID とデプロイ時に指定したリージョン名が追加で含まれます。
本来なら GitHub と連携させてデプロイをさせることでプレビュー環境を作るのですが、動作検証中に毎回 GitHub と連携するのは手間なので Static Web Apps CLI を使ってローカルからデプロイして検証しました。
この辺りは別途ブログに書こうと思っていますが、Static Web Apps CLI には swa deploy コマンドが用意されていて、簡単に任意のディレクトリをデプロイできるため非常に便利です。
Azure Portal から Deployment Token をコピーしてくれば、以下のようなコマンドでサクッとデプロイ可能です。--env を指定することで任意の名前のプレビュー環境へのデプロイも可能です。
swa deploy ./dist --env staging --deployment-token ***
これで作成したプレビュー環境に対してアクセスを行ってみると、Entra ID 側に登録されているコールバック URL が一致しないというエラーが発生して、ログインに失敗することが確認出来ます。このコールバック URL は Entra ID アプリケーション側に登録をしていないので、エラーが発生するのは当然です。
Static Web Apps がリリースされた当初から URL が Pull Request 毎に変わる結果、Entra ID のように外部に URL を登録するサービスが使いにくいと言われていて、その対応策としてプレビュー環境の拡張としてブランチ環境や名前付き環境が導入されました。
詳細は以下のドキュメントを参照していただくとして、このブランチ環境や名前付き環境を使うと、URL の固定化が可能となるためコールバック URL を登録するのは容易になります。
これでステージング環境のように予め決められたプレビュー環境であれば、Entra ID 認証を有効化出来るようになりましたが、やはり Pull Request 単位でのプレビュー環境の需要は多いので実現したいです。SPA のレビューの度にローカルで実行するのは正直厳しいです。
今回の場合は Entra ID アプリケーションのリダイレクト URL を可変に出来れば解決するので調べると、なんと Entra ID アプリケーションのリダイレクト URL は条件付きながらワイルドカードが利用できることが分かりました。これは完全に求めていた機能でした。
サブドメイン部分をワイルドカードで登録できるので、今回のプレビュー環境であれば問題なく利用できるはずです。但しドキュメントにもあるようにワイルドカードは推奨されておらず、絶対 URL が強く推奨されている点は頭に入れておく必要があります。
Though it's possible to set a redirect URI with a wildcard by using the manifest editor, we strongly recommend you adhere to section 3.1.2 of RFC 6749. and use only absolute URIs.
Redirect URI (reply URL) restrictions - Microsoft identity platform | Microsoft Learn
そしてワイルドカードが利用できるのは組織向けのアプリケーションだけとなっているため、ユースケースとしては今回のように開発中に利用することが想定されていると考えられます。
全く推奨されてはいない関係上、通常の UI ではワイルドカードを含む URL は登録出来ません。ドキュメントにもあるようにマニフェストを直接編集することで対応します。
注意点としてはワイルドカードはサブドメインに対して指定できるため、挙動としてはワイルドカード証明書と同じ仕様になっているようです。つまり https://*.example.com は指定できますが https://test-*.example.com のような指定は出来ませんし、ワイルドカードの対象となるのはその階層だけです。
従って Static Web Apps のプレビュー環境向けにワイルドカード設定を追加する際には、以下のようにプレビュー環境向けのコールバック URL を追加する形で対応します。
これで本番向けとプレビュー環境向けの両方に対応した Entra ID アプリケーションの設定が出来ました。
早速、先ほどはコールバック URL のミスマッチエラーが発生したプレビュー環境にアクセスすると、今度は問題なく Entra ID 認証に成功してページが表示されることが確認出来ました。
GitHub Actions を利用したデプロイの設定を行って、実際に Pull Request を作成したタイミングで作成されるプレビュー環境にアクセスしてみましたが、こちらも問題なく Entra ID 認証が行われてページが表示できています。ワイルドカードなので Pull Request が複数作られても問題なく動作します。
これで Managed Functions を利用した Static Web Apps 向けのアプリケーションであれば、問題なく Entra ID 認証付きで Pull Request の変更内容をプレビュー出来るようになりました。
最後に本題とは関係ないですが、GitHub Actions で Static Web Apps に Pull Request のプレビュー環境を作成した際に、完了のコメントが書き込まれないケースがあるようです。これは GitHub Actions の権限のデフォルト値が変更され、Pull Request への書き込みの権限が外れたことが原因です。
以下の Issue にある通り、permissions で Pull Request への書き込み権限を付与すると解決します。
自動生成された GitHub Actions の Workflow ファイルには permissions が定義されていないようなので、デフォルト値が変更されたことを知らないとはまりそうです。
