Azure Static Web Apps の認証と承認

Azure Static Web Apps は、認証エクスペリエンスが効率化されています。 事前構成済みの一連のプロバイダーに既定でアクセスできるほか、必要に応じてカスタム プロバイダーを登録することもできます。

  • すべてのユーザーは、有効なプロバイダーに対して認証を行うことができます。
  • ユーザーはログイン後、既定では anonymous ロールと authenticated ロールに属します。
  • 許可されているユーザーは、staticwebapp.config.json ファイルに定義されたルールで、制限されたルートにアクセスできます。
  • ユーザーは、プロバイダー固有の招待またはカスタム Azure Active Directory プロバイダー登録を通じてカスタム ロールに参加します。
  • すべての認証プロバイダーは、既定で有効になっています。
  • 事前構成済みのプロバイダーは次のとおりです。
    • Azure Active Directory
    • GitHub
    • Twitter

認証と承認のサブジェクトは、ルーティングの概念とかなり共通点があります。ルーティングの概念については、アプリケーション構成ガイドに詳しく説明されています。

ロール

静的 Web アプリにアクセスするすべてのユーザーは、1 つまたは複数のロールに属しています。 ユーザーは、以下の 2 つの組み込みロールに属することができます。

  • 匿名:すべてのユーザーは自動的に "匿名" ロールに属します。
  • 認証済み:ログインしているすべてのユーザーは、"認証済み" ロールに属します。

組み込みロール以外に新しいロールを作成して、招待を使ってユーザーに割り当て、staticwebapp.config.json ファイルで参照することができます。

ロール管理

ユーザーをロールに追加する

ユーザーをロールに追加するには、ユーザーを特定のロールに関連付けることができる招待を生成します。 ロールは、staticwebapp.config.json ファイル内で定義および管理されます。

注意

グループ管理用の招待の発行を避けたい場合は、カスタム Azure Active Directory プロバイダーを登録してください。

招待を作成する

招待は個々の承認プロバイダーに固有であるため、サポートするプロバイダーを選択する際には、アプリのニーズを考慮してください。 プロバイダーによって、ユーザーの電子メール アドレスが公開される場合もあれば、サイトのユーザー名のみが提示される場合もあります。

承認プロバイダー 公開されるユーザーの情報
Azure Active Directory メール アドレス
GitHub username
Twitter username
  1. Azure portal 上で Static Web Apps リソースに移動します。
  2. [設定] 下で、 [ロール管理] をクリックします。
  3. [招待] ボタンをクリックします。
  4. オプションの一覧から [承認プロバイダー] を選択します。
  5. [Invitee details](招待者の詳細) ボックスに、受信者のユーザー名または電子メール アドレスを追加します。
    • GitHub および Twitter の場合は、ユーザー名を入力します。 それ以外の場合は、受信者の電子メール アドレスを入力します。
  6. [ドメイン] ドロップダウンから静的サイトのドメインを選択します。
    • 選択されたドメインは、招待に表示されるドメインになります。 サイトに関連付けられているカスタム ドメインがある場合は、そのカスタム ドメインを選択することができます。
  7. [ロール] ボックスにロール名のコンマ区切りの一覧を追加します。
  8. 招待が有効なまま維持される最大時間数を入力します。
    • 指定できる最大上限は、168 時間 (7 日間) です。
  9. [生成] ボタンをクリックします。
  10. [Invite link](招待リンク) ボックスからリンクをコピーします。
  11. アプリへのアクセス権を付与するユーザーに招待リンクを電子メールで送信します。

ユーザーが招待のリンクをクリックすると、該当のアカウントでログインするように求められます。 正常にログインが行われると、選択されたロールにユーザーが関連付けられます。

注意事項

ルート規則が、選択された認証プロバイダーと競合しないようにしてください。 ルート規則によってプロバイダーがブロックされると、ユーザーは招待を承諾することができなくなります。

ロールの割り当てを更新する

  1. Azure portal 上で Static Web Apps リソースに移動します。
  2. [設定] 下で、 [ロール管理] をクリックします。
  3. 一覧上でユーザーをクリックします。
  4. [ロール] ボックスで、ロールの一覧を編集します。
  5. [更新] ボタンをクリックします。

ユーザーの削除

  1. Azure portal 上で Static Web Apps リソースに移動します。
  2. [設定] 下で、 [ロール管理] をクリックします。
  3. 一覧上でユーザーを探します。
  4. そのユーザーの行のチェック ボックスをオンにします。
  5. [削除] ボタンをクリックします。

ユーザーを削除する際には、以下の点に注意してください。

  1. ユーザーを削除すると、そのユーザーのアクセス許可は無効になります。
  2. 世界規模での反映には、数分かかる場合があります。
  3. ユーザーがアプリに再び追加される場合、userId は変更されます

個人が特定される情報を削除する

エンド ユーザーとしてアプリケーションに同意すると、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 を使用することに注意してください。

システム フォルダー

Azure Static Web Apps では、/.auth システム フォルダーを使用して、承認関連の API へのアクセスが提供されています。 /.auth フォルダー下のいずれかのルートをエンドユーザーに直接公開するのではなく、ルーティング規則を作成してわかりやすい URL を作ることを検討してください。

ログイン

次の表を使用して、プロバイダー固有のルートを確認します。

承認プロバイダー ログイン ルート
Azure Active Directory /.auth/login/aad
GitHub /.auth/login/github
Twitter /.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>

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
}

制限

一般的な制限事項と限度については、クォータに関する記事を参照してください。

次のステップ

1 外部証明書は保留されています。