Azure Static Web Apps プレビューの認証と承認Authentication and authorization for Azure Static Web Apps Preview

Azure Static Web Apps では、次のプロバイダーでの認証を管理することで、認証エクスペリエンスを効率化しています。Azure Static Web Apps streamlines the authentication experience by managing authentication with the following providers:

  • Azure Active DirectoryAzure Active Directory
  • GitHubGitHub
  • FacebookFacebook
  • Google1Google1
  • TwitterTwitter

プロバイダー固有の招待によってユーザーはロールに関連付けられ、承認されたユーザーには、routes.json ファイルに定義された規則によってルートへのアクセス権が付与されます。Provider-specific invitations associate users with roles, and authorized users are granted access to routes by rules defined in the routes.json file.

すべての認証プロバイダーは、既定で有効になっています。All authentication providers are enabled by default. 認証プロバイダーを制限するには、カスタム ルート規則によってアクセスをブロックします。To restrict an authentication provider, block access with a custom route rule.

認証と承認のトピックは、ルーティングの概念とかなり重複します。The topics of authentication and authorization significantly overlap with routing concepts. この記事と併せて、ルーティング ガイドを是非お読みください。Make sure to read the routing guide along with this article.

ロールRoles

静的 Web アプリにアクセスするすべてのユーザーは、1 つまたは複数のロールに属しています。Every user who accesses a static web app belongs to one or more roles. ユーザーは、以下の 2 つの組み込みロールに属することができます。There are two built-in roles that users can belong to:

  • 匿名:すべてのユーザーは自動的に "匿名" ロールに属します。anonymous: All users automatically belong to the anonymous role.
  • 認証済み:ログインしているすべてのユーザーは、"認証済み" ロールに属します。authenticated: All users who are logged in belong to the authenticated role.

組み込みロール以外に新しいロールを作成して、招待を使ってユーザーに割り当て、routes.json ファイルで参照することができます。Beyond the built-in roles, you can create new roles, assign them to users via invitations, and reference them in the routes.json file.

ロール管理Role management

ユーザーをロールに追加するAdd a user to a role

Web サイトにユーザーを追加するには、特定のロールにユーザーを関連付けできる招待を生成します。To add users to your web site, you generate invitations which allow you to associate users to specific roles. ロールは、route. json ファイル内で定義および管理されています。Roles are defined and maintained in the routes.json file.

招待を作成するCreate an invitation

招待は個々の承認プロバイダーに固有であるため、サポートするプロバイダーを選択する際には、アプリのニーズを考慮してください。Invitations are specific to individual authorization-providers, so consider the needs of your app as you select which providers to support. プロバイダーによって、ユーザーの電子メール アドレスが公開される場合もあれば、サイトのユーザー名のみが提示される場合もあります。Some providers expose a user's email address, while others only provide the site's username.

承認プロバイダーAuthorization provider 公開されるユーザーの情報Exposes a user's
Azure Active DirectoryAzure Active Directory メール アドレスemail address
FacebookFacebook メール アドレスemail address
GitHubGitHub usernameusername
Google1Google1 メール アドレスemail address
TwitterTwitter usernameusername
  1. Azure portal 上で Static Web Apps リソースに移動します。Navigate to a Static Web Apps resource in the Azure portal.
  2. [設定] 下で、 [ロール管理] をクリックします。Under Settings, click on Role Management.
  3. [招待] ボタンをクリックします。Click on the Invite button.
  4. オプションの一覧から [承認プロバイダー] を選択します。Select an Authorization provider from the list of options.
  5. [Invitee details](招待者の詳細) ボックスに、受信者のユーザー名または電子メール アドレスを追加します。Add either the username or email address of the recipient in the Invitee details box.
    • GitHub および Twitter の場合は、ユーザー名を入力します。For GitHub and Twitter, you enter the username. それ以外の場合は、受信者の電子メール アドレスを入力します。For all others, enter the recipient's email address.
  6. [ドメイン] ドロップダウンから静的サイトのドメインを選択します。Select the domain of your static site from the Domain drop-down.
    • 選択されたドメインは、招待に表示されるドメインになります。The domain you select is the domain that appears in the invitation. サイトに関連付けられているカスタム ドメインがある場合は、そのカスタム ドメインを選択することができます。If you have a custom domain associated with your site, you probably want to choose the custom domain.
  7. [ロール] ボックスにロール名のコンマ区切りの一覧を追加します。Add a comma-separated list of role names in the Role box.
  8. 招待が有効なまま維持される最大時間数を入力します。Enter the maximum number of hours you want the invitation to remain valid.
    • 指定できる最大上限は、168 時間 (7 日間) です。The maximum possible limit is 168 hours, which is 7 days.
  9. [生成] ボタンをクリックします。Click the Generate button.
  10. [Invite link](招待リンク) ボックスからリンクをコピーします。Copy the link from the Invite link box.
  11. アプリへのアクセス権を付与するユーザーに招待リンクを電子メールで送信します。Email the invitation link to the person you're granting access to your app.

ユーザーが招待のリンクをクリックすると、該当のアカウントでログインするように求められます。When the user clicks the link in the invitation, they're prompted to log in with their corresponding account. 正常にログインが行われると、選択されたロールにユーザーが関連付けられます。Once successfully logged-in, the user is associated with the selected roles.

注意事項

ルート規則が、選択された認証プロバイダーと競合しないようにしてください。Make sure your route rules don't conflict with your selected authentication providers. ルート規則によってプロバイダーがブロックされると、ユーザーは招待を承諾することができなくなります。Blocking a provider with a route rule would prevent users from accepting invitations.

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

  1. Azure portal 上で Static Web Apps リソースに移動します。Navigate to a Static Web Apps resource in the Azure portal.
  2. [設定] 下で、 [ロール管理] をクリックします。Under Settings, click on Role Management.
  3. 一覧上でユーザーをクリックします。Click on the user in the list.
  4. [ロール] ボックスで、ロールの一覧を編集します。Edit the list of roles in the Role box.
  5. [更新] ボタンをクリックします。Click the Update button.

ユーザーの削除Remove user

  1. Azure portal 上で Static Web Apps リソースに移動します。Navigate to a Static Web Apps resource in the Azure portal.
  2. [設定] 下で、 [ロール管理] をクリックします。Under Settings, click on Role Management.
  3. 一覧上でユーザーを探します。Locate the user in the list.
  4. そのユーザーの行のチェック ボックスをオンにします。Check the checkbox on the user's row.
  5. [削除] ボタンをクリックします。Click the Delete button.

ユーザーを削除する際には、以下の点に注意してください。As you remove a user, keep in mind the following items:

  1. ユーザーを削除すると、そのユーザーのアクセス許可は無効になります。Removing a user invalidates their permissions.
  2. 世界規模での反映には、数分かかる場合があります。Worldwide propagation may take a few minutes.
  3. ユーザーがアプリに再び追加される場合、userId は変更されますIf the user is added back to the app, the userId changes.

個人が特定される情報を削除するRemove personal identifying information

エンドユーザーとしてアプリケーションに同意すると、ID プロバイダーに応じて電子メール アドレスまたはユーザー名に、そのアプリケーションからアクセスできるようになります。When you grant consent to an application as an end-user, the application has access to your email address or your username depending on the identity provider. この情報が提供されたら、アプリケーションの所有者は、個人が特定される情報をどのように管理するかを決定します。Once this information is provided, the owner of the application decides how to manage personally identifying information.

この情報をシステムから取り消すには、エンドユーザーは、個々の Web アプリの管理者に連絡する必要があります。End-users need to contact administrators of individual web apps to revoke this information from their systems.

Azure Static Web Apps プラットフォームから個人が特定される情報を削除し、今後の要求でプラットフォームからこの情報が提供されないようにするには、以下の URL を使用して要求を送信します。To remove personally identifying information from the Azure Static Web Apps platform, and prevent the platform from providing this information on future requests, submit a request using the URL:

https://identity.azurestaticapps.net/.auth/purge/<AUTHENTICATION_PROVIDER_NAME>

今後の要求でプラットフォームから個々のアプリに対してこの情報が提供されないようにするには、以下の URL へ要求を送信します。To prevent the platform from providing this information on future requests to individual apps, submit a request to the following URL:

https://<WEB_APP_DOMAIN_NAME>/.auth/purge/<AUTHENTICATION_PROVIDER_NAME>

システム フォルダーSystem folder

Azure Static Web Apps では、/.auth システム フォルダーを使用して、承認関連の API へのアクセスが提供されています。Azure Static Web Apps uses the /.auth system folder to provide access to authorization-related APIs. /.auth フォルダー下のいずれかのルートをエンドユーザーに直接公開するのではなく、ルーティング規則を作成してわかりやすい URL を作ることを検討してください。Rather than exposing any of the routes under the /.auth folder directly to end users, consider creating routing rules to create friendly URLs.

ログインLogin

次の表を使用して、プロバイダー固有のログイン ルートを確認します。Use the following table to find the provider-specific login route.

承認プロバイダーAuthorization provider ログイン ルートLogin route
Azure Active DirectoryAzure Active Directory /.auth/login/aad
FacebookFacebook /.auth/login/facebook
GitHubGitHub /.auth/login/github
Google1Google1 /.auth/login/google
TwitterTwitter /.auth/login/twitter

たとえば、GitHub にログインするために、次のスニペットのようなログイン リンクを含めることができます。For example, to login with GitHub you could include a login link like the following snippet:

<a href="/.auth/login/github">Login</a>

複数のプロバイダーをサポートすることを選択した場合は、それぞれに対応するプロバイダー固有のリンクを Web サイト上に公開する必要があります。If you chose to support more than one provider, then you need to expose a provider-specific link for each on your website.

ルート規則を使用して、既定のプロバイダーを /login のようなわかりやすいルートにマップできます。You can use a route rule to map a default provider to a friendly route like /login.

{
  "route": "/login",
  "serve": "/.auth/login/github"
}

ログイン後のリダイレクトPost login redirect

ログイン後にユーザーが特定のページに戻るようにするには、post_login_redirect_uri クエリ文字列パラメーターに URL を指定します。If you want a user to return to a specific page after login, provide a URL in post_login_redirect_uri query string parameter.

LogoutLogout

/.auth/logout ルートでは、Web サイトからユーザーをログアウトします。The /.auth/logout route logs users out from the website. 次の例に示すように、サイト ナビゲーションにユーザーがログアウトできるリンクを追加することが可能です。You can add a link to your site navigation to allow the user to log out as shown in the following example.

<a href="/.auth/logout">Log out</a>

ルート規則を使用して、 /login のようなわかりやすいルートにマップできます。You can use a route rule to map a friendly route like /logout.

{
  "route": "/logout",
  "serve": "/.auth/logout"
}

ログアウト後のリダイレクトPost logout redirect

ログアウト後にユーザーが特定のページに戻るようにするには、post_logout_redirect_uri クエリ文字列パラメーターに URL を指定します。If you want a user to return to a specific page after logout, provide a URL in post_logout_redirect_uri query string parameter.

承認プロバイダーをブロックするBlock an authorization provider

承認プロバイダーを使用しないように、アプリを制限することができます。You may want to restrict your app from using an authorization provider. たとえば、お使いのアプリ上で、電子メール アドレスを公開するプロバイダーのみに統一したい場合があります。For instance, your app may want to standardize only on providers that expose email addresses.

プロバイダーをブロックするには、ルート規則を作成して、ブロックされたプロバイダー固有のルートへの要求に 404 を返すことができます。To block a provider, you can create route rules to return a 404 for requests to the blocked provider-specific route. たとえば、プロバイダーとして Twitter を制限するには、次のルート規則を追加します。For example, to restrict Twitter as provider, add the following route rule.

{
  "route": "/.auth/login/twitter",
  "statusCode": "404"
}

制限Restrictions

一般的な制限事項と限度については、クォータに関する記事を参照してください。See the Quotas article for general restrictions and limitations.

次のステップNext steps

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