Azure Static Web Apps でのカスタム認証
Azure Static Web Apps が提供するマネージド認証では、Azure が管理するプロバイダー登録が使用されます。 登録の柔軟性を高めるため、既定値をカスタム登録でオーバーライドできます。
またカスタム認証により、OpenID Connect をサポートするカスタム プロバイダーを構成できます。 この構成では、複数の外部プロバイダーを登録できます。
カスタム登録を使うと、事前構成済みのすべてのプロバイダーが無効になります。
Note
カスタム認証は、Azure Static Web Apps Standard プランでのみ使用できます。
カスタム ID プロバイダーを構成する
カスタム ID プロバイダーは、構成ファイルの auth セクションで構成されます。
ソース管理にシークレットが入り込まないようにするため、構成ではアプリケーション設定が調べられ、構成ファイルに一致する名前があるかどうかが確認されます。 また、Azure Key Vault にシークレットを格納することも選択できます。
登録を作成するには、以下のアプリケーション設定の作成から始めます。
| 設定名 | 値 |
|---|---|
AZURE_CLIENT_ID |
Microsoft Entra アプリ登録のアプリケーション (クライアント) ID。 |
| `AZURE_CLIENT_SECRET_APP_SETTING_NAME | Microsoft Entra アプリ登録のクライアント シークレットを保持するアプリケーション設定の名前。 |
次に、下記のサンプルを使用して、構成ファイルでプロバイダーを構成します。
Microsoft Entra プロバイダーは、2 つの異なるバージョンで提供されています。 バージョン 1 では、ペイロードでユーザー情報を返すことができると、userDetailsClaim が明示的に定義されています。 これに対してバージョン 2 では、既定でユーザー情報が返されます。それは openIdIssuer URL 内の v2.0 によって指定されます。
Microsoft Entra バージョン 1
{
"auth": {
"identityProviders": {
"azureActiveDirectory": {
"userDetailsClaim": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
"registration": {
"openIdIssuer": "https://login.microsoftonline.com/<TENANT_ID>",
"clientIdSettingName": "AZURE_CLIENT_ID",
"clientSecretSettingName": "AZURE_CLIENT_SECRET_APP_SETTING_NAME"
}
}
}
}
}
<TENANT_ID> を Microsoft Entra テナント ID に置き換えてください。
Microsoft Entra バージョン 2
{
"auth": {
"identityProviders": {
"azureActiveDirectory": {
"registration": {
"openIdIssuer": "https://login.microsoftonline.com/<TENANT_ID>/v2.0",
"clientIdSettingName": "AZURE_CLIENT_ID",
"clientSecretSettingName": "AZURE_CLIENT_SECRET_APP_SETTING_NAME"
}
}
}
}
}
<TENANT_ID> を Microsoft Entra テナント ID に置き換えてください。
Microsoft Entra ID を構成する方法の詳細については、「App Service の認証と認可に関するドキュメント」で既存の登録の使用について参照してください。
サインインできるアカウントを構成する方法については、「アプリケーションによってサポートされるアカウントを変更する」と「Microsoft Entra アプリを Microsoft Entra テナントの一連のユーザーに制限する」を参照してください。
Note
Microsoft Entra ID の構成セクションは azureActiveDirectory ですが、プラットフォームでは、ログイン、ログアウト、ユーザー情報の消去のために、これを URL 内の aad にエイリアス化します。 詳細については、認証と承認に関するセクションを参照してください。
カスタム証明書
Microsoft Entra ID のアプリ登録にカスタム証明書を追加するには、次の手順のようにします。
まだない場合は、Microsoft キー コンテナーに証明書をアップロードします。
静的 Web アプリでマネージド ID を追加します。
ユーザー割り当てマネージド ID の場合は、静的サイト オブジェクトの
keyVaultReferenceIdentityプロパティを、ユーザー割り当てマネージド ID のresourceIdに設定します。マネージド ID がシステム割り当てである場合は、このステップをスキップします。
マネージド ID に次のアクセス ポリシーを付与します。
- シークレット: 取得/一覧表示
- 証明書: 取得/一覧表示
次の例に示すように、
azureActiveDirectory構成セクションの認証構成セクションをclientSecretCertificateKeyVaultReferenceの値で更新します。{ "auth": { "rolesSource": "/api/GetRoles", "identityProviders": { "azureActiveDirectory": { "userDetailsClaim": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "registration": { "openIdIssuer": "https://login.microsoftonline.com/common/v2.0", "clientIdSettingName": "AZURE_CLIENT_ID", "clientSecretCertificateKeyVaultReference": "@Microsoft.KeyVault(SecretUri=https://<KEY_VAULT_NAME>.azure.net/certificates/<CERTIFICATE_NAME>/<CERTIFICATE_VERSION_ID>)", "clientSecretCertificateThumbprint": "*" } } } } }<>で囲まれたプレースホルダーを実際の値に必ず置き換えてください。シークレット URI で、キー コンテナー名と証明書名を指定します。 バージョンを固定する場合は、証明書のバージョンを含めます。それ以外の場合はバージョンを省略して、ランタイムが証明書の最新バージョンを選択できるようにします。
証明書の拇印の最新バージョンを常にプルするには、
clientSecretCertificateThumbprintを*に設定します。
認証コールバック
ID プロバイダーには、ログインまたはログアウトの要求を完了するためにリダイレクト URL が必要です。 ほとんどのプロバイダーでは、コールバック URL を許可リストに追加する必要があります。 次のエンドポイントは、リダイレクト先として使用できます。
| Type | URL パターン |
|---|---|
| ログイン | https://<YOUR_SITE>/.auth/login/<PROVIDER_NAME_IN_CONFIG>/callback |
| Logout | https://<YOUR_SITE>/.auth/logout/<PROVIDER_NAME_IN_CONFIG>/callback |
Microsoft Entra ID を使用している場合は、 <PROVIDER_NAME_IN_CONFIG> プレースホルダーの値として aad を使用します。
Note
これらの URL は、認証プロバイダーからの応答を受信するために Azure Static Web Apps により提供されます。これらのルートでページを作成する必要はありません。
ログイン、ログアウト、ユーザーの詳細
カスタム ID プロバイダーを使用するには、次の URL パターンを使用します。
| アクション | パターン |
|---|---|
| ログイン | /.auth/login/<PROVIDER_NAME_IN_CONFIG> |
| Logout | /.auth/logout |
| ユーザーの詳細 | /.auth/me |
| ユーザーの詳細の削除 | /.auth/purge/<PROVIDER_NAME_IN_CONFIG> |
Microsoft Entra ID を使用している場合は、 <PROVIDER_NAME_IN_CONFIG> プレースホルダーの値として aad を使用します。
ロールの管理
静的 Web アプリにアクセスするすべてのユーザーは、1 つまたは複数のロールに属しています。 ユーザーは、以下の 2 つの組み込みロールに属することができます。
- 匿名: すべてのユーザーは自動的に "匿名" ロールに属します。
- 認証済み: サインインしているすべてのユーザーは、認証済みロールに属します。
組み込みロール以外にカスタム ロールをユーザーに割り当て、staticwebapp.config.json ファイルで参照することができます。
ユーザーをロールに追加する
ユーザーをロールに追加するには、ユーザーを特定のロールに関連付けることができる招待を生成します。 ロールは、staticwebapp.config.json ファイル内で定義および管理されます。
招待状の作成
招待は個々の承認プロバイダーに固有であるため、サポートするプロバイダーを選択する際には、アプリのニーズを考慮してください。 プロバイダーによって、ユーザーの電子メール アドレスが公開される場合もあれば、サイトのユーザー名のみが提示される場合もあります。
| 承認プロバイダー | 公開 |
|---|---|
| Microsoft Entra ID | メール アドレス |
| GitHub | username |
| x | username |
招待を作成するには、次の手順のようにします。
- Azure portal 上で Static Web Apps リソースに移動します。
- [設定] で [ロール管理] を選択します。
- [招待] を選びます。
- オプションの一覧から [承認プロバイダー] を選択します。
- [Invitee details]\(招待者の詳細\) ボックスに、受信者のユーザー名または電子メール アドレスを追加します。
- GitHub および X の場合はユーザー名を入力します。 それ以外の場合は、受信者の電子メール アドレスを入力します。
- [ドメイン] ドロップダウン メニューから静的サイトのドメインを選択します。
- 選択されたドメインは、招待に表示されるドメインになります。 サイトに関連付けられているカスタム ドメインがある場合は、そのカスタム ドメインを選択します。
- [ロール] ボックスにロール名のコンマ区切りの一覧を追加します。
- 招待が有効なまま維持される最大時間数を入力します。
- 指定できる最大上限は、168 時間 (7 日間) です。
- [Generate] \(生成) を選択します。
- [Invite link]\(招待リンク\) ボックスからリンクをコピーします。
- アクセス権を付与するユーザーに招待リンクを電子メールで送信します。
ユーザーが招待のリンクを選択すると、該当のアカウントでサインインするように求められます。 正常にサインインが行われると、選択されたロールにユーザーが関連付けられます。
注意事項
ルート規則が、選択された認証プロバイダーと競合しないようにしてください。 ルート規則によってプロバイダーがブロックされると、ユーザーは招待を承諾することができなくなります。
ロールの割り当てを更新する
- Azure portal 上で Static Web Apps リソースに移動します。
- [設定] で [ロール管理] を選択します。
- ユーザーを一覧から選びます。
- [ロール] ボックスで、ロールの一覧を編集します。
- [更新] を選択します。
ユーザーを削除する
- Azure portal 上で Static Web Apps リソースに移動します。
- [設定] で [ロール管理] を選択します。
- 一覧上でユーザーを探します。
- そのユーザーの行のチェック ボックスをオンにします。
- 削除を選択します。
ユーザーを削除する際には、以下の点に注意してください。
- ユーザーを削除すると、そのユーザーのアクセス許可は無効になります。
- 世界中に反映されるには、数分かかる場合があります。
- ユーザーがアプリに再び追加される場合、
userIdは変更されます。