Azure App Service組み込みの認証機能(Easy Auth)でプロバイダーの認証エンドポイントへ送信するGETパラメータを追加する
いわさです。
Azure App ServiceにはEasy Authと呼ばれる組み込みの認証機能があります。
こちらを使うとWebアプリケーションへの修正を行わずに、Azure基盤機能のみでIDプロバイダーによる認証機能をWebアプリケーションへ簡単に組み込むことが可能です。
Microsoft以外のサードパーティのIDプロバイダーではFacebook, Google, Twitterなどが利用でき、その他では任意のOIDCプロバイダーも利用可能です。
一部プロバイダは認証エンドポイントで追加のパラメータを受け付ける場合があり、パラメータを追加したい場合にどう対応したら良いか考えてみました。
公式ドキュメントを読み解く限り、パラメータの設定箇所はなさそうだったので他のサービスと組み合わせて実現出来るか見てみます。
組み込みの動作
まずは標準のEasy Authを構成します。
ここではサードパーティIDプロバイダにFacebookを指定してみたいと思います。
構成手順は以下のページに手順が公開されています。
まず、App Serviceをデプロイし、Facebook Developerでアプリを登録します。
OAuthリダイレクトURIにApp ServiceのURLを指定し、App ServiceのEasy AuthではFacebookアプリのアプリIDとシークレットを設定すれば完了です。
アクセス時に認証が必要になります。
ここではauth_typeを指定してみたいと思います。
App Service URIへアクセスすると、Easy Authの設定に従って事前に組み込まれたFacebook認証エンドポイントへリダイレクトされます。
ユーザー操作によって認証と認可が行われると、パラメータに含まれるredirect_uriに従って、App Seriviceへ認証情報とともに戻ってきます。
Easy Authで設定出来るは認可スコープまでです。
auth_typeなど追加のパラメータを指定したい場合はどうしたら良いでしょうか。
レイヤーを追加してレスポンスを編集する
ドキュメントを見る限りでは、App Serivice Easy Authの機能として提供されていないように見えます。
ここでは、レスポンス時のlocationヘッダーを上書き出来ればとりあえずの目的は達成できそうです。
AzureではApp Serviceの前面にAzure Front DoorかAzure Application Gatewayを配置することが出来ます。
そして、それらの機能はApp Serviceのレスポンスヘッダーを編集することが可能です。
今日はこの機能を使って実現出来るか試してみたいと思います。
Azure Front Door追加
この記事ではAzure Front Doorを使ってみます。
試してないですが、Application Gatewayでも実現出来ると思います。
リダイレクト先を変更する
Easy Authを使うと、Front Door経由でアクセスしたとしても、認証後のリターン先がApp ServiceのURIで固定されてしまいます。
これはApp Serivceの設定を変更することで挙動を変更出来ます。
ポータルから操作出来ないので構成ファイルで変更を行います。
下記ハイライト部分をNoProxy->Standardへ変更するだけです。
設定の変更はaz restを使っても良いですが、Resource Explorerを使うと楽です。
{
...
"identityProviders": {
"azureActiveDirectory": {
...
},
"facebook": {
"enabled": true,
"registration": {
"appId": "123456789012345",
"appSecretSettingName": "FACEBOOK_PROVIDER_AUTHENTICATION_SECRET"
},
"login": {
"scopes": []
}
},
"gitHub": {
...
},
"google": {
...
},
"twitter": {
...
},
"legacyMicrosoftAccount": {
...
},
"apple": {
...
}
},
"login": {
...
},
"httpSettings": {
"requireHttps": true,
"routes": {
"apiPrefix": "/.auth"
},
"forwardProxy": {
"convention": "Standard"
}
}
}
}
redirect_uriがFront DoorのURIに変わりました。
ついでにIDプロバイダー（Facebook）側の「有効なOAuthリダイレクトURI」もFront DoorのURIへ変更しましょう。
Facebookの場合だとリファラーを確認しているのか、警告が表示されます。
ヘッダー書き換え
さて、最後にFront Doorのルールエンジンを構成してレスポンスヘッダーを書き換えます。
ここでは簡易的に、リファラーとCookie値を見てヘッダーの追加を行いました。
もう少し認証フローや要件にあわせてカスタマイズが必要な気がします。
追加したルールエンジンはルーティング規則へ関連付けするのを忘れないように気をつけましょう。
エッジサービスだからか、反映まで少しタイムラグがありました。
パラメータを追加出来た
Front DoorのURIでGETリクエストを送信してレスポンスを確認してみましょう。
Facebook側の認証エンドポイント(locationヘッダー)へ追加パラメータを渡すことが出来ました。
まとめ
認証エンドポイントへ追加のパラメータを渡すこと自体はどうにか出来ました。
どのタイミングでどのパラメータを渡すかが、ルールエンジンでカバー出来る範囲であればありなんじゃないかなと思う一方で、一定以上のカスタマイズが必要であればアプリケーションレイヤーで機能を実装するのが正しいアプローチなんだろうなと思いました。
細かい条件の制御まで必要になるので標準のEasyAuthの範囲ではそこまで入ってないのだと思います。
![[アップデート] Azure App Service ポータル画面から Azure Load Testing テストを実行しやすくなったので使ってみました](https://devio2023-media.developers.io/wp-content/uploads/2022/08/devio-eyecatch-Azure.png)
