Web API

Web API アプリは、Web API からリソースを取得する必要がある Web アプリケーションです。 このシナリオでは、Web アプリケーションが Web API の認証と呼び出しに使用できる ID の種類が 2 つあります。

• アプリケーション ID - このシナリオでは、OAuth 2.0 クライアント資格情報付与を使用してアプリケーションとして認証し、Web API にアクセスします。 Web API はユーザーに関する情報を受け取らないので、アプリケーション ID を使用する場合、Web API は Web アプリケーションがそれを呼び出していることを検出することしかできません。 アプリケーションがユーザーに関する情報を受信した場合、アプリケーション プロトコルを介して送信され、Azure AD によって署名されることはありません。 Web API は、Web アプリケーションがユーザーを認証したことを信頼します。 このため、このパターンは信頼されたサブシステムと呼ばれます。
• 委任されたユーザー ID - このシナリオは、OpenID Connect と、機密クライアントによる OAuth 2.0 承認コード付与の 2 つの方法で実現できます。 Web アプリケーションはユーザーのアクセス トークンを取得します。これは、ユーザーが Web アプリケーションに対して正常に認証されたことと、Web アプリケーションが Web API を呼び出す委任されたユーザー ID を取得できたことを Web API に証明します。 このアクセス トークンは、要求で Web API に送信され、ユーザーを承認し、目的のリソースを返します。

アプリケーション ID と委任されたユーザー ID の種類の両方について、以下のフローで説明します。 それらの主な違いは、ユーザーがサインインして Web API にアクセスする前に、委任されたユーザー ID が最初に承認コードを取得する必要があるということです。

ダイアグラム

プロトコル フロー

OAuth 2.0 クライアント資格情報付与を使用したアプリケーション ID

1. ユーザーが Web アプリケーションで Azure AD にサインインしている (詳細については、「 Web アプリ 」セクションを参照してください)。
2. Web アプリケーションは、Web API に対して認証し、目的のリソースを取得できるように、アクセス トークンを取得する必要があります。 資格情報、アプリケーション ID、および Web API のアプリケーション ID URI を指定して、Azure AD のトークン エンドポイントに要求を行います。
3. Azure AD はアプリケーションを認証し、Web API の呼び出しに使用される JWT アクセス トークンを返します。
4. HTTPS 経由で、Web アプリケーションは返された JWT アクセス トークンを使用して、要求の Authorization ヘッダーに "Bearer" という指定の JWT 文字列を Web API に追加します。 その後、Web API は JWT トークンを検証し、検証が成功した場合は目的のリソースを返します。

OpenID Connect を使用した委任されたユーザー ID

1. ユーザーは、Azure AD を使用して Web アプリケーションにサインインします (上記の「Web ブラウザーから Web アプリケーション」セクションを参照)。 Web アプリケーションのユーザーが Web アプリケーションに代わって Web API を呼び出すことを許可することにまだ同意していない場合、ユーザーは同意する必要があります。 アプリケーションに必要なアクセス許可が表示され、管理者レベルのアクセス許可がある場合、ディレクトリ内の通常のユーザーは同意できません。 この同意プロセスはマルチテナント アプリケーションにのみ適用され、シングル テナント アプリケーションには適用されません。アプリケーションには必要なアクセス許可が既に与えられます。 ユーザーがサインインすると、Web アプリケーションは、ユーザーに関する情報と承認コードを含む ID トークンを受け取りました。
2. Azure AD によって発行された承認コードを使用して、Web アプリケーションは、承認コード、クライアント アプリケーションの詳細 (アプリケーション ID とリダイレクト URI)、および目的のリソース (Web API のアプリケーション ID URI) を含む要求を Azure AD のトークン エンドポイントに送信します。
3. 承認コードと Web アプリケーションと Web API に関する情報は、Azure AD によって検証されます。 検証が成功すると、Azure AD は JWT アクセス トークンと JWT 更新トークンの 2 つのトークンを返します。
4. HTTPS 経由で、Web アプリケーションは返された JWT アクセス トークンを使用して、要求の Authorization ヘッダーに "Bearer" という指定の JWT 文字列を Web API に追加します。 その後、Web API は JWT トークンを検証し、検証が成功した場合は目的のリソースを返します。

OAuth 2.0 承認コード付与を使用した委任されたユーザー ID

1. ユーザーは既に Web アプリケーションにサインインしており、その認証メカニズムは Azure AD から独立しています。
2. Web アプリケーションでは、アクセス トークンを取得するために承認コードが必要であるため、ブラウザーを介して Azure AD の承認エンドポイントに要求を発行し、認証が成功した後に Web アプリケーションのアプリケーション ID とリダイレクト URI を指定します。 ユーザーが Azure AD にサインインします。
3. Web アプリケーションのユーザーが Web アプリケーションに代わって Web API を呼び出すことを許可することにまだ同意していない場合、ユーザーは同意する必要があります。 アプリケーションに必要なアクセス許可が表示され、管理者レベルのアクセス許可がある場合、ディレクトリ内の通常のユーザーは同意できません。 この同意は、シングル テナント アプリケーションとマルチテナント アプリケーションの両方に適用されます。 シングルテナントの場合、管理者はユーザーに代わって同意を行う管理者の権限を行使できます。 これは、Azure portal の [Grant Permissions] ボタンを使用して行うことができます。
4. ユーザーが同意すると、Web アプリケーションはアクセス トークンを取得するために必要な承認コードを受け取ります。
5. Azure AD によって発行された承認コードを使用して、Web アプリケーションは、承認コード、クライアント アプリケーションの詳細 (アプリケーション ID とリダイレクト URI)、および目的のリソース (Web API のアプリケーション ID URI) を含む要求を Azure AD のトークン エンドポイントに送信します。
6. 承認コードと Web アプリケーションと Web API に関する情報は、Azure AD によって検証されます。 検証が成功すると、Azure AD は JWT アクセス トークンと JWT 更新トークンの 2 つのトークンを返します。
7. HTTPS 経由で、Web アプリケーションは返された JWT アクセス トークンを使用して、要求の Authorization ヘッダーに "Bearer" という指定の JWT 文字列を Web API に追加します。 その後、Web API は JWT トークンを検証し、検証が成功した場合は目的のリソースを返します。

コード サンプル

Web アプリケーションから Web API へのシナリオのコード サンプルを参照してください。 また、頻繁に確認してください。新しいサンプルが頻繁に追加されます。 Web アプリケーションから Web API。

アプリの登録

Azure AD v1.0 エンドポイントにアプリケーションを登録するには、「アプリの登録」を参照してください。

• シングル テナント - アプリケーション ID と委任されたユーザー ID の両方の場合、Web アプリケーションと Web API を Azure AD の同じディレクトリに登録する必要があります。 Web API は、一連のアクセス許可を公開するように構成できます。これは、Web アプリケーションのリソースへのアクセスを制限するために使用されます。 委任されたユーザー ID の種類が使用されている場合、Web アプリケーションは、Azure portal の [ 他のアプリケーションへのアクセス許可 ] ドロップダウン メニューから目的のアクセス許可を選択する必要があります。 アプリケーション ID の種類が使用されている場合、この手順は必要ありません。
• マルチテナント - まず、Web アプリケーションが機能するために必要なアクセス許可を示すように構成されます。 この必要なアクセス許可の一覧は、移行先ディレクトリのユーザーまたは管理者がアプリケーションに同意した場合にダイアログに表示されます。これにより、アプリケーションが組織で使用できるようになります。 一部のアプリケーションでは、組織内のすべてのユーザーが同意できるユーザー レベルのアクセス許可のみが必要です。 他のアプリケーションには、組織内のユーザーが同意できない管理者レベルのアクセス許可が必要です。 ディレクトリ管理者のみが、このレベルのアクセス許可を必要とするアプリケーションに同意できます。 ユーザーまたは管理者が同意すると、Web アプリケーションと Web API の両方がディレクトリに登録されます。

トークンの有効期限

Web アプリケーションが承認コードを使用して JWT アクセス トークンを取得すると、JWT 更新トークンも受け取ります。 アクセス トークンの有効期限が切れると、更新トークンを使用して、ユーザーに再サインインを要求することなく、ユーザーを再認証できます。 この更新トークンは、ユーザーの認証に使用され、新しいアクセス トークンと更新トークンが生成されます。

次のステップ

• その他の アプリケーションの種類とシナリオの詳細については、
• Azure AD 認証の基本 について説明します