Azure AD ログインを使用するように App Service または Azure Functions アプリを構成する
別の認証プロバイダーを選択すると、それにジャンプします。
この記事では、アプリで Microsoft ID プラットフォーム (Azure AD) を認証プロバイダーとして使ってユーザーがサインインするように、Azure App Service または Azure Functions の認証を構成する方法について説明します。
App Service 認証機能では、Microsoft ID プラットフォームを使ってアプリの登録を自動的に作成できます。 また、ユーザーまたはディレクトリ管理者が個別に作成した登録を使用することもできます。
Note
新しい登録を作成するオプションは、政府機関向けクラウドでは使用できません。 代わりに、 登録を個別に定義します。
オプション 1: 新しいアプリ登録を自動作成する
アプリ登録を別個に作成する必要がない限り、このオプションを使用してください。 認証を簡単に有効にすることができ、必要なのは数回のクリックのみです。 Azure AD でのアプリ登録は、作成後にカスタマイズできます。
Azure portal にサインインし、アプリに移動します。
左側のメニューで [認証] を選択します。 [ID プロバイダーの追加] をクリックします。
[ID プロバイダー] ドロップダウンで [Microsoft] を選択します。 既定では、新しい登録を作成するオプションが選択されています。 登録の名前またはサポートされているアカウントの種類を変更できます。
クライアント シークレットが作成され、
MICROSOFT_PROVIDER_AUTHENTICATION_SECRETという名前のスロット固定のアプリケーション設定 として保存され ます。 Azure Key Vault でシークレットを管理する場合は、Key Vault 参照を使用するように、この設定を後で更新することができます。これがアプリケーション用に構成された最初の ID プロバイダーである場合は、「App Service 認証設定」のセクションも表示されます。 それ以外の場合は、次の手順に進むことができます。
これらのオプションは、アプリケーションが認証されていない要求にどのように応答するかを決定し、既定の選択によって、この新しいプロバイダーにログインするためのすべての要求がリダイレクトされます。 [認証設定] の横にある [編集] を選択すると、この動作をメインの [認証] 画面からカスタマイズすることができます。 これらのオプションの詳細については、「認証フロー」を参照してください。
(オプショナル) [次へ: アクセス許可] をクリックし、アプリで必要な Microsoft Graph のアクセス許可を追加します。 これらはアプリの登録に追加されますが、後で変更することもできます。
[追加] をクリックします。
これで、アプリケーションで認証に Microsoft ID プラットフォームを使う準備ができました。 [認証] 画面にプロバイダーが一覧表示されます。 そこから、このプロバイダーの構成を編集または削除できます。
Azure Storage と Microsoft Graph にアクセスする Web アプリの Azure AD ログインを構成する例については、こちらのチュートリアルを参照してください。
オプション 2: 個別に作成された既存の登録を使用する
既存のアプリ登録を使用するように App Service 認証を構成できます。 既存のアプリ登録を使用する最も一般的なケースは、次のとおりです。
- お使いのアカウントに、Azure AD テナントでアプリ登録を作成するためのアクセス許可がない。
- アプリが属しているものとは異なる Azure AD テナントにあるアプリ登録を使用する必要がある。
- 新しい登録を作成するオプションは、政府機関向けクラウドでは使用できません。
手順 1: App Service アプリのために Azure AD でアプリ登録を作成する
アプリ登録の作成中、後で App Service アプリで認証を構成するときに必要になる次の情報を収集してください。
- クライアント ID
- テナント ID
- クライアント シークレット (オプショナル)
- アプリケーション ID URI
アプリを登録するには、次の手順に従います。
Azure portal にサインインし、 [App Services] を探して選択してから、アプリを選択します。 アプリの URL をメモしておきます。 Azure Active Directory アプリの登録を構成するときにそれを使用します。
ポータル メニューで、[Azure Active Directory] を選択します。
左側のナビゲーションで、[アプリの登録]>[新規登録] を選択します。
[アプリケーションの登録] ページで、アプリの登録の [名前] を入力します。
[サポートされているアカウントの種類] で、このアプリにアクセスできるアカウントの種類を選択します。
[リダイレクト URI] セクションで、プラットフォームとして [Web] を選択し、「
<app-url>/.auth/login/aad/callback」と入力します。 たとえば、「https://contoso.azurewebsites.net/.auth/login/aad/callback」のように入力します。[登録] を選択します。
アプリの登録が作成されたら、後のために [アプリケーション (クライアント) ID] と [ディレクトリ (テナント) ID] をコピーします。
[Implicit grant and hybrid flows](暗黙的な許可とハイブリッド フロー) で [ID トークン] を有効にして、App Service からの OpenID Connect ユーザーのサインインを許可します。 [保存] を選択します。
(オプショナル) 左側のナビゲーションで、[ブランド化とプロパティ] を選択します。 [ホーム ページ URL] に App Service アプリの URL を入力し、 [保存] を選択します。
左側のナビゲーションで、[API の公開]>[設定]>[保存] を選択します。 この値によって、リソースとしての使用時、アプリケーションが一意に特定されます。アクセスを付与するトークンを要求できます。 作成するスコープのプレフィックスとして使用されます。
シングルテナント アプリの場合、
api://<application-client-id>形式である既定値を使用できます。 テナントの検証済みドメインの 1 つに基づき、https://contoso.com/apiのような、もっと読みやすい URI を指定することもできます。 マルチテナントのアプリの場合は、カスタム URI を指定する必要があります。 アプリ ID URI で使用できる形式の詳細については、アプリ登録のベスト プラクティス リファレンス ページを参照してください。[スコープ の追加] を選択します。
- [スコープ名] に、「user_impersonation」と入力します。
- [同意できるユーザー] で、ユーザーがこのスコープに同意できるようにする場合は、[管理者とユーザー] を選択します。
- 同意ページでユーザーに表示する同意スコープの名前と説明をテキスト ボックスに入力します。 たとえば、「 <アプリケーション名> にアクセスする」と入力します。
- [スコープの追加] を選択します。
(オプショナル) クライアント シークレットを作成するには、次の手順に従います。
- 左側のナビゲーションで、[証明書とシークレット]>[クライアント シークレット]>[新しいクライアント シークレット] を選択します。
- 説明と有効期限を入力し、 [追加] を選びます
- [値] フィールドで、クライアント シークレットの値をコピーします。 このページから移動すると、再び表示されることはありません。
(オプショナル) 複数の応答 URL を追加するには、 [認証] を選択します。
手順 2: App Service アプリで Azure Active Directory を有効にする
Azure portal にサインインし、アプリに移動します。
左側のナビゲーションで、[認証]>[ID プロバイダーの追加]>[Microsoft] を選択します。
[アプリの登録の種類] で、次のいずれかを選択します。
このディレクトリ内の既存アプリの登録を選択: 現在のテナントからアプリ登録を選択し、必要なアプリ情報を自動的に収集します。
既存アプリの登録の詳細を提供します: 現在のテナントで登録のクエリを実行するアクセス許可がアカウントにない場合、または別のテナントにあるアプリ登録の場合に詳細を指定します。 このオプションでは、次の構成の詳細を入力する必要があります。
フィールド 説明 アプリケーション (クライアント) ID アプリの登録のアプリケーション (クライアント) ID を使用します。 クライアント シークレット アプリの登録で生成したクライアント シークレットを使用します。 クライアント シークレットを使用すると、ハイブリッド フローが使用され、App Service によってアクセス トークンと更新トークンが返されます。 クライアント シークレットが設定されていない場合は、暗黙的なフローが使用され、ID トークンのみが返されます。 これらのトークンはプロバイダーによって送信され、EasyAuth トークン ストアに格納されます。 発行者の URL <authentication-endpoint>/<tenant-id>/v2.0を使用し、<authentication-endpoint> をクラウド環境の認証エンドポイント (たとえば、グローバル Azure の場合、"https://login.microsoftonline.com"") に置き換え、さらに、<tenant-id> を、アプリ登録が作成されたディレクトリ (テナント) ID に置き換えます。 この値は、ユーザーを正しい Azure AD テナントにリダイレクトするため、および適切なメタデータをダウンロードして、適切なトークン署名キーやトークン発行者のクレーム値などを特定するために使用されます。 Azure AD v1 を使用するアプリケーションの場合は、URL で/v2.0を省略します。許可されるトークン対象ユーザー 構成された [アプリケーション (クライアント) ID] は、"常に" 許可された対象ユーザーであると暗黙的に見なされます。 これがクラウドまたはサーバー アプリであり、クライアント App Service アプリから認証トークンを受け入れる場合 (認証トークンは X-MS-TOKEN-AAD-ID-TOKEN ヘッダーで取得できます)、クライアント アプリのアプリケーション (クライアント) ID をここに追加します。 クライアント シークレットが、
MICROSOFT_PROVIDER_AUTHENTICATION_SECRETという名前のスロット固定のアプリケーション設定 として保存され ます。 Azure Key Vault でシークレットを管理する場合は、Key Vault 参照を使用するように、この設定を後で更新することができます。
これがアプリケーション用に構成された最初の ID プロバイダーである場合は、「App Service 認証設定」のセクションも表示されます。 それ以外の場合は、次の手順に進むことができます。
これらのオプションは、アプリケーションが認証されていない要求にどのように応答するかを決定し、既定の選択によって、この新しいプロバイダーにログインするためのすべての要求がリダイレクトされます。 [認証設定] の横にある [編集] を選択すると、この動作をメインの [認証] 画面からカスタマイズすることができます。 これらのオプションの詳細については、「認証フロー」を参照してください。
[追加] をクリックします。
これで、アプリケーションで認証に Microsoft ID プラットフォームを使う準備ができました。 [認証] 画面にプロバイダーが一覧表示されます。 そこから、このプロバイダーの構成を編集または削除できます。
カスタマイズされた認可ポリシーを追加する
作成されたアプリ登録では、Azure AD テナントにおける受信要求を認証します。 また、既定では、テナント内のだれでもアプリにアクセスできるようにします。これは、多くのアプリにとって問題ありません。 ただし、一部のアプリケーションでは、承認の決定を行い、アクセスをさらに制限する必要があります。 多くの場合、アプリケーション コードはカスタム承認ロジックを処理するのに最適な場所です。 ただし、一般的なシナリオについては、Microsoft ID プラットフォームに、アクセスを制限するために使用できる組み込みのチェックが用意されています。
このセクションでは、App Service authentication V2 API を使用して組み込みチェックを有効にする方法について説明します。 現時点では、これらの組み込みチェックを構成する唯一の方法は、Azure Resource Manager テンプレートまたは REST API を使用することです。
API オブジェクト内では、Azure Active Directory ID プロバイダーの構成には、次の構造のように defaultAuthorizationPolicy オブジェクトを含めることができる validation セクションがあります。
{
"validation": {
"defaultAuthorizationPolicy": {
"allowedApplications": [],
"allowedPrincipals": {
"identities": []
}
}
}
}
| プロパティ | 説明 |
|---|---|
defaultAuthorizationPolicy |
アプリにアクセスするために満たす必要がある要件のグループ。 アクセスは、構成された各プロパティに対する論理 AND に基づいて許可されます。 allowedApplications と allowedPrincipals の両方が構成されている場合、着信要求が受け入れられるためには、両方の要件を満たす必要があります。 |
allowedApplications |
アプリを呼び出しているクライアント リソースを表す文字列アプリケーション クライアント ID の許可リスト。 このプロパティが空でない配列として構成されている場合、リストで指定されたアプリケーションによって取得されたトークンのみが受け入れられます。 このポリシーは、受信トークン (アクセス トークンである必要があります) の appid または azp クレームを評価します。 Microsoft ID プラットフォーム クレームのリファレンスに関するページを参照してください。 |
allowedPrincipals |
着信要求によって表されるプリンシパルがアプリにアクセスできるかどうかを判断するチェックのグループ。 allowedPrincipals の充足は、構成されたプロパティに対する論理 OR に基づいています。 |
identities (allowedPrincipalsで) |
アクセス権を持つユーザーまたはアプリケーションを表す文字列オブジェクト ID の許可リスト。 このプロパティが空でない配列として構成されている場合、要求によって表されるユーザーまたはアプリケーションがリストで指定されていれば、allowedPrincipals の要件を満たすことができます。このポリシーは、受信トークンの oid クレームを評価します。 Microsoft ID プラットフォーム クレームのリファレンスに関するページを参照してください。 |
これらの組み込みチェックに失敗した要求には、HTTP 403 Forbidden 応答が渡されます。
App Service にアクセスするようにクライアント アプリを構成する
前のセクションでは、ユーザーを認証するために App Service または Azure 関数を登録しました。 このセクションでは、N 層アーキテクチャなどにおいて、Azure AD でネイティブ クライアントまたはデーモン アプリを登録して、ユーザーまたはそれらのために App Service によって公開される API へのアクセスを要求できるようにする方法を説明します。 ユーザーを認証するだけの場合は、このセクションの手順を完了する必要はありません。
ネイティブ クライアント アプリケーション
サインインしているユーザーの代わりに App Service アプリの API へのアクセスを要求するようにネイティブ クライアントを登録できます。
ポータル メニューで、[Azure Active Directory] を選択します。
左側のナビゲーションで、[アプリの登録]>[新規登録] を選択します。
[アプリケーションの登録] ページで、アプリの登録の [名前] を入力します。
[リダイレクト URI] で、[パブリック クライアント (モバイル&デスクトップ)] を選択し、URL「
<app-url>/.auth/login/aad/callback」を入力します。 たとえば、「https://contoso.azurewebsites.net/.auth/login/aad/callback」のように入力します。[登録] を選択します。
アプリの登録が作成されたら、 [アプリケーション (クライアント) ID] の値をコピーします。
Note
Microsoft Store アプリケーションの場合は、代わりにパッケージ SID を URI として使用します。
左側のナビゲージョンで、[API のアクセス許可]>[アクセス許可の追加]>[自分の API] を選択します。
App Service アプリ用に以前に作成したアプリの登録を選択します。 アプリの登録が表示されない場合は、「App Service アプリに対するアプリ登録を Azure AD で作成する」で user_impersonation スコープを追加したことを確認します。
[委任されたアクセス許可] で、 [user_impersonation] を選択し、 [アクセス許可の追加] を選択します。
これで、ユーザーに代わって App Service アプリにアクセスを要求できるネイティブ クライアント アプリケーションが構成されました。
デーモン クライアント アプリケーション (サービス ツー サービスのコール)
N 層アーキテクチャでクライアント アプリは、(ユーザーのためにではなく) クライアント アプリ自体のために App Service または関数アプリを呼び出すトークンを取得できます。 このシナリオは、ログイン ユーザーなしでタスクを実行する非対話型デーモン アプリケーションに役立ちます。 これには標準の OAuth 2.0 クライアント資格情報の付与が使用されます。
- ポータル メニューで、[Azure Active Directory] を選択します。
- 左側のナビゲーションで、[アプリの登録]>[新規登録] を選択します。
- [アプリケーションの登録] ページで、アプリの登録の [名前] を入力します。
- デーモン アプリケーションの場合、リダイレクト URI は不要であるため、空のままでかまいません。
- [登録] を選択します。
- アプリの登録が作成されたら、 [アプリケーション (クライアント) ID] の値をコピーします。
- 左側のナビゲーションで、[証明書とシークレット]>[クライアント シークレット]>[新しいクライアント シークレット] を選択します。
- 説明と有効期限を入力し、 [追加] を選びます
- [値] フィールドで、クライアント シークレットの値をコピーします。 このページから移動すると、再び表示されることはありません。
これで、resource パラメーターをターゲット アプリのアプリケーション ID URI に設定することで、クライアント ID とクライアント シークレットを使用してアクセス トークンを要求できます。 その後、標準の OAuth 2.0 Authorization ヘッダーを使用して、得られたアクセス トークンをターゲット アプリに提示できます。また、App Service の認証によって、通常通りにトークンが検証および使用され、呼び出し元 (この場合はユーザーではなくアプリである) が認証されたことが示されます。
現時点で、これによって Azure AD テナント内のすべてのクライアント アプリケーションがアクセス トークンを要求し、ターゲット アプリに対して認証を行うことができます。 また、"承認" を実施して特定のクライアント アプリケーションのみを許可する場合は、追加の構成を行う必要があります。
- 保護する App Service または関数アプリを表すアプリ登録のマニフェストで、アプリ ロールを定義します。
- 承認する必要があるクライアントを表すアプリの登録で、 [API のアクセス許可]>[アクセス許可の追加]>[自分の API] を選択します。
- 前に作成したアプリの登録を選択します。 アプリの登録が表示されない場合は、アプリ ロールを追加したことを確認してください。
- [アプリケーションのアクセス許可] で、前に作成したアプリ ロールを選択し、 [アクセス許可の追加] を選択します。
- クライアント アプリケーションがアクセス許可を要求することを承認するために、必ず [管理者の同意を与える] をクリックしてください。
- (ロールを追加する前の) 前述のシナリオと同様に、これで、同じターゲット
resourceのアクセス トークンを要求できます。アクセス トークンには、クライアント アプリケーションのために承認されたアプリ ロールを含むroles要求が含まれます。 - これで、ターゲット App Service または関数アプリのコード内で、必要なロールがトークンに存在しているか検証できます (これは App Service 認証では実行されません)。 詳しくは、「ユーザー要求へのアクセス」をご覧ください。
これで、独自の ID を使用して App Service アプリにアクセスできるデーモン クライアント アプリケーションが構成されました。
ベスト プラクティス
認証の設定に使用する構成に関係なく、次のベスト プラクティスによってテナントとアプリケーションのセキュリティが強化されます。
- 各 App Service アプリを、Azure AD での独自のアプリ登録を使用して構成します。
- App Service アプリごとに独自のアクセス許可と同意を付与します。
- デプロイ スロットごとに個別のアプリ登録を使用することで、環境間でアクセス許可を共有することを回避します。 新しいコードをテストするとき、このプラクティスは、問題が運用アプリに影響を与えることを回避する上で役立つことがあります。