Azure Static Web Apps の認証と認可

Azure Static Web Apps は、認証に GitHub、Twitter、および Azure Active Directory (Azure AD) を使用するために他のアクションや構成を必要としない、合理化された認証エクスペリエンスを提供します。

この記事では、既定の動作、サインインとサインアウトを設定する方法、認証プロバイダーをブロックする方法などについて説明します。

すべての事前構成済みプロバイダーを無効にするカスタム プロバイダーを登録できます。

前提条件

Azure Static Web Apps を使用した認証と認可については、次の既定値とリソースに注意してください。

既定値:

• すべてのユーザーは、事前に構成されたプロバイダーで認証できます
  • GitHub
  • Twitter
  • Azure Active Directory (Azure AD)
  • 認証プロバイダーを制限するには、カスタム ルート規則によってアクセスをブロックします
• サインイン後、ユーザーは anonymous ロールと authenticated ロールに属します。 ロールの詳細については、「ロールの管理」を参照してください

リソース:

• staticwebapp.config.json ファイルでルールを定義して、許可されているユーザーが制限されたルートにアクセスできるようにします
• 組み込みの招待システムを使用してユーザーのカスタム役割を割り当てる
• API 関数を使用してサインイン時にユーザーにカスタム役割をプログラムで割り当てる
• 認証と認可は、ルーティングの概念とはかなり重複していることを理解します。ルーティングの概念については、アプリケーション構成ガイドに詳しく説明されています
• カスタム Azure AD プロバイダーを構成して、特定の Azure AD テナントへのサインインを制限します。 事前構成済みの Azure AD プロバイダーを使用すると、任意の Microsoft アカウントでサインインできます。

サインインを設定する

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

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

承認プロバイダー	サインイン ルート
Azure AD	/.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>

認証されていないユーザーがサインインしたら、参照元のページにそのユーザーをリダイレクトすることができます。 この動作を構成するには、次の例のように、post_login_redirect_uri を .referrer に設定する応答のオーバーライド規則を作成します。

{
  "responseOverrides": {
    "401": {
      "redirect": "/.auth/login/github?post_login_redirect_uri=.referrer",
      "statusCode": 302
    }
  }
}

サインアウトの設定

/.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
}

個人データの削除

エンド ユーザーとしてアプリケーションに同意すると、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 AD を使おうとしている場合は、<AUTHENTICATION_PROVIDER_NAME> プレースホルダーの値として aad を使用します。

ヒント

一般的な制限と制約については、「クォータ」を参照してください。

次のステップ

ルートを使用して、許可されたロールを設定してページ アクセスを制御する

関連記事

• カスタム認証を使用してロールを管理する
• アプリケーション構成ガイド、ルーティングの概念
• ユーザーの認証と承認のデータにアクセスする