Azure Static Web Apps の認証と承認
Azure Static Web Apps は、認証エクスペリエンスが効率化されています。 事前構成済みの一連のプロバイダーに既定でアクセスできるほか、必要に応じてカスタム プロバイダーを登録することもできます。
- すべてのユーザーは、有効なプロバイダーに対して認証を行うことができます。
- ユーザーはログイン後、既定では
anonymous
ロールとauthenticated
ロールに属します。 - 許可されているユーザーは、staticwebapp.config.json ファイルに定義されたルールで、制限されたルートにアクセスできます。
- ユーザーには、組込みの招待システムを使用して、カスタム ロールが割り当てられます。
- API 関数を使用し、ログイン時にプログラムでユーザーにカスタム ロールを割り当てることができます。
- すべての認証プロバイダーは、既定で有効になっています。
- 認証プロバイダーを制限するには、カスタム ルート規則によってアクセスをブロックします。 カスタム プロバイダーを構成すると、事前構成済みのプロバイダーも無効になります。
- 事前構成済みのプロバイダーは次のとおりです。
- Azure Active Directory1
- GitHub
1 構成済みの Azure Active Directory プロバイダーは、Microsoft アカウントでサインインを許可します。 特定の Active Directory テナントにログインを制限するには、[カスタム Azure Active Directory プロバイダー] を構成します。
認証と承認のサブジェクトは、ルーティングの概念とかなり共通点があります。ルーティングの概念については、アプリケーション構成ガイドに詳しく説明されています。
システム フォルダー
Azure Static Web Apps では、/.auth
システム フォルダーを使用して、承認関連の API へのアクセスが提供されています。 /.auth
フォルダー下のいずれかのルートをエンドユーザーに直接公開するのではなく、/.auth
を作成してわかりやすい URL を作ることを検討してください。
ログイン
次の表を使用して、プロバイダー固有のルートを確認します。
承認プロバイダー | ログイン ルート |
---|---|
Azure Active Directory | /.auth/login/aad |
GitHub | /.auth/login/github |
/.auth/login/twitter |
たとえば、GitHub にログインするために、次のスニペットのようなリンクを含めることができます。
<a href="/.auth/login/github">Login</a>
複数のプロバイダーをサポートすることを選択した場合は、それぞれに対応するプロバイダー固有のリンクを Web サイト上に公開する必要があります。
ルート規則を使用して、既定のプロバイダーを /login のようなわかりやすいルートにマップできます。
{
"route": "/login",
"redirect": "/.auth/login/github"
}
ログイン後のリダイレクト
ログイン後にユーザーが特定のページに戻るようにするには、post_login_redirect_uri
クエリ文字列パラメーターに完全修飾 URL を指定します。
次に例を示します。
<a href="/.auth/login/github?post_login_redirect_uri=https://zealous-water.azurestaticapps.net/success">Login</a>
また、認証されていないユーザーがログインしたら、参照元のページにそのユーザーをリダイレクトすることができます。 この動作を構成するには、post_login_redirect_uri
を .referrer
に設定する、応答のオーバーライド規則を作成します。
次に例を示します。
{
"responseOverrides": {
"401": {
"redirect": "/.auth/login/github?post_login_redirect_uri=.referrer",
"statusCode": 302
}
}
}
Logout
/.auth/logout
ルートでは、Web サイトからユーザーをログアウトします。 次の例に示すように、サイト ナビゲーションにユーザーがログアウトできるリンクを追加することが可能です。
<a href="/.auth/logout">Log out</a>
ルート規則を使用して、 /login のようなわかりやすいルートにマップできます。
{
"route": "/logout",
"redirect": "/.auth/logout"
}
ログアウト後のリダイレクト
ログアウト後にユーザーが特定のページに戻るようにするには、post_logout_redirect_uri
クエリ文字列パラメーターに URL を指定します。
認証プロバイダーをブロックする
認証プロバイダーを使用しないように、アプリを制限することができます。 たとえば、お使いのアプリ上で、電子メール アドレスを公開するプロバイダーのみに統一したい場合があります。
プロバイダーをブロックするには、ルート規則を作成して、ブロックされたプロバイダー固有のルートへの要求に 404 状態コードを返すことができます。 たとえば、プロバイダーとして Twitter を制限するには、次のルート規則を追加します。
{
"route": "/.auth/login/twitter",
"statusCode": 404
}
ロール
静的 Web アプリにアクセスするすべてのユーザーは、1 つまたは複数のロールに属しています。 ユーザーは、以下の 2 つの組み込みロールに属することができます。
- 匿名:すべてのユーザーは自動的に "匿名" ロールに属します。
- 認証済み:ログインしているすべてのユーザーは、"認証済み" ロールに属します。
組み込みロール以外にカスタム ロールをユーザーに割り当て、staticwebapp.config.json ファイルで参照することができます。
ロール管理
ユーザーをロールに追加する
ユーザーをロールに追加するには、ユーザーを特定のロールに関連付けることができる招待を生成します。 ロールは、staticwebapp.config.json ファイル内で定義および管理されます。
招待を作成する
招待は個々の承認プロバイダーに固有であるため、サポートするプロバイダーを選択する際には、アプリのニーズを考慮してください。 プロバイダーによって、ユーザーの電子メール アドレスが公開される場合もあれば、サイトのユーザー名のみが提示される場合もあります。
承認プロバイダー | 公開されるユーザーの情報 |
---|---|
Azure Active Directory | メール アドレス |
GitHub | username |
username |
- Azure portal 上で Static Web Apps リソースに移動します。
- [設定] 下で、 [ロール管理] をクリックします。
- [招待] ボタンをクリックします。
- オプションの一覧から [承認プロバイダー] を選択します。
- [Invitee details](招待者の詳細) ボックスに、受信者のユーザー名または電子メール アドレスを追加します。
- GitHub および Twitter の場合は、ユーザー名を入力します。 それ以外の場合は、受信者の電子メール アドレスを入力します。
- [ドメイン] ドロップダウンから静的サイトのドメインを選択します。
- 選択されたドメインは、招待に表示されるドメインになります。 サイトに関連付けられているカスタム ドメインがある場合は、そのカスタム ドメインを選択することができます。
- [ロール] ボックスにロール名のコンマ区切りの一覧を追加します。
- 招待が有効なまま維持される最大時間数を入力します。
- 指定できる最大上限は、168 時間 (7 日間) です。
- [生成] ボタンをクリックします。
- [Invite link](招待リンク) ボックスからリンクをコピーします。
- アプリへのアクセス権を付与するユーザーに招待リンクを電子メールで送信します。
ユーザーが招待のリンクをクリックすると、該当のアカウントでログインするように求められます。 正常にログインが行われると、選択されたロールにユーザーが関連付けられます。
注意事項
ルート規則が、選択された認証プロバイダーと競合しないようにしてください。 ルート規則によってプロバイダーがブロックされると、ユーザーは招待を承諾することができなくなります。
ロールの割り当てを更新する
- Azure portal 上で Static Web Apps リソースに移動します。
- [設定] 下で、 [ロール管理] をクリックします。
- 一覧上でユーザーをクリックします。
- [ロール] ボックスで、ロールの一覧を編集します。
- [更新] ボタンをクリックします。
ユーザーの削除
- Azure portal 上で Static Web Apps リソースに移動します。
- [設定] 下で、 [ロール管理] をクリックします。
- 一覧上でユーザーを探します。
- そのユーザーの行のチェック ボックスをオンにします。
- [削除] ボタンをクリックします。
ユーザーを削除する際には、以下の点に注意してください。
個人が特定される情報を削除する
エンド ユーザーとしてアプリケーションに同意すると、ID プロバイダーに応じてメール アドレスまたはユーザー名に、そのアプリケーションからアクセスできるようになります。 この情報が提供されたら、アプリケーションの所有者は、個人が特定される情報をどのように管理するかを決定します。
この情報をシステムから取り消すには、エンド ユーザーは、個々の Web アプリの管理者に連絡する必要があります。
Azure Static Web Apps プラットフォームから個人が特定される情報を削除し、今後の要求でプラットフォームからこの情報が提供されないようにするには、以下の URL を使用して要求を送信します。
https://identity.azurestaticapps.net/.auth/purge/<AUTHENTICATION_PROVIDER_NAME>
今後の要求でプラットフォームから個々のアプリに対してこの情報が提供されないようにするには、以下の URL へ要求を送信します。
https://<WEB_APP_DOMAIN_NAME>/.auth/purge/<AUTHENTICATION_PROVIDER_NAME>
Azure Active Directory を使用する場合は、<AUTHENTICATION_PROVIDER_NAME>
プレースホルダーの値として aad
を使用することに注意してください。
制限
一般的な制限事項と限度については、クォータに関する記事を参照してください。