Azure Static Web Appsで事前構成済みのプロバイダーで認証設定をしてみた

いわさです。

Azure Static Web Appsでは静的サイトをホスティングして簡単に公開することが可能ですが、認証機能を追加することも出来ます。
事前構成済みプロバイダーとカスタムプロバイダーから選択が可能で、事前構成済みプロバイダーはFreeプランでも利用が可能です。カスタムプロバイダーはStandardプランが必要です。

本日はFreeプランのAzure Static Web AppsにAzure ADによる認証機能を追加してみました。
以下のようなHTMLページがパブリック公開されている状態からスタートします。

事前構成済み認証の追加

事前構成済みプロバイダーとして、AzureAD / GitHub / Twitter の3つが用意されています。
そしてそれぞれのログインルートが用意されているので、そちらを使ってユーザーに認証をしてもらう形です。
例えば、サイトURLがhttps://hogehoge.azurestaticapps.net/だとすると、AzureADのログインルートはhttps://hogehoge.azurestaticapps.net//.auth/login/aadとなります。

ここではAzureADを使おうと思います。

まず、アプリへ認証を追加するために、構成ファイルstaticwebapp.config.jsonをルートへ配置します。
Static Web Appsでは構成ファイルを使うことでアプリへ様々な追加設定を行うことが出来ます。

そのひとつのroutesでは、パスごとにallowedRolesで許可ロールを指定することが出来ます。
ここではデフォルトのauthenticatedロールを使っていますが、Static Web Appsのロール機能から個別にロールを割り当ててカスタマイズすることも可能です。
その場合、AzureADだとメールアドレスを指定してユーザーを招待します。

サイト全体（すべてのパス）を対象にallowedRolesを指定し、認証が必要な場合は先程のAzureADログインルートへリダイレクトさせるように設定します。

staticwebapp.config.json

{
    "routes": [
        {
            "route": "/*",
            "allowedRoles": [
                "authenticated"
            ]
        }
    ],
    "responseOverrides": {
        "401": {
            "statusCode": 302,
            "redirect": "/.auth/login/aad"
        }
    }
}

index.htmlへアクセスすると、AzureADログイン画面へリダイレクトされると思います。

認証をして、アプリへの認可を行います。

遷移することが出来ました。

Twitter, GitHubをブロック

実はこの状態だと、AzureAD以外の事前構成されたプロバイダーで認証した状態でもアクセスが可能です。
Twitterのログインルート(/.auth/login/twitter)へ直接アクセスしてみます。

Twitterの認証・認可画面が表示されます。
先程と同じように許可していってみましょう。

アクセス出来てしまいました。

対策として、AzureAD以外の事前構成済みプロバイダーへのログインルートをブロックする方法があります。
以下ハイライト部分を追加しましょう。

staticwebapp.config.json

{
    "routes": [
        {
            "route": "/.auth/login/twitter",
            "statusCode": 404
        },
        {
            "route": "/.auth/login/github",
            "statusCode": 404
        },
        {
            "route": "/*",
            "allowedRoles": [
                "authenticated"
            ]
        }
    ],
    "responseOverrides": {
        "401": {
            "statusCode": 302,
            "redirect": "/.auth/login/aad"
        }
    }
}

無事、404になってくれました。

なお、ルートの追加位置を誤るとエラーとなるので気をつけてください。

staticwebapp.config.json

{
    "routes": [
        {
            "route": "/*",
            "allowedRoles": [
                "authenticated"
            ]
        },
        {
            "route": "/.auth/login/twitter",
            "statusCode": 404
        },
        {
            "route": "/.auth/login/github",
            "statusCode": 404
        }
    ],
    "responseOverrides": {
        "401": {
            "statusCode": 302,
            "redirect": "/.auth/login/aad"
        }
    }
}

Encountered an issue while validating staticwebapp.config.json: A route is covered up by a wildcard route and would not be evaluated. Route: /.auth/login/twitter, Wildcard(s): /*. Please either delete or move the unreachable route.

さいごに。AzureADでの認証が必須にはなったが...

これでAzureADで認証した時だけサイトへアクセスを許可することが出来ました。
ただし、実はこの方法だと全く関係の無いテナントのAzureADで認証してもアクセス出来ます。
さらに、Microsoft（非組織）アカウントでもアクセスすることが出来ます。

これが望ましくないケースもあると思います。
その場合、特定テナントにログインを制限する方法があります。
実現するためにはカスタム認証機能を使います。

このカスタム認証機能を使うと様々なIDプロバイダーに対応することが出来るようになります。
なお、冒頭紹介したようにカスタム認証についてはStandardプランが必要です。

この機能を使ったAzureAD特定テナントへの制限は次回以降試してみたいと思います。