セールス: 1-800-867-1380

Azure AD の認証シナリオ

発行: 2014年4月

更新日: 2014年6月

Azure Active Directory (Azure AD) は、コーディングを手軽に開始可能にするために、さまざまなプラットフォームのためのオープン ソース ライブラリだけでなく、OAuth 2.0 や OpenID Connect などの業界標準プロトコルをサポートする Identity as a Service を提供して、開発者の認証を簡略化します。このドキュメントは、Azure AD がサポートするさまざまなシナリオを説明し、Azure AD を開始する方法を示します。このドキュメントは次のセクションに分割されます。

Azure AD での認証の基本的な概念に詳しくない場合は、このセクションを参照してください。それ以外の場合は、「アプリケーションの種類とシナリオ」に進んでください。

ID が必要とされる最も基本的なシナリオを検討してみましょう。たとえば、Web アプリケーションで認証する必要がある Web ブラウザーのユーザーがいるとします。このシナリオは、「Web ブラウザー対 Web アプリケーション」セクションで詳細に説明されています。Azure AD の機能が図解されてシナリオの動作が概念化されているため、スタート地点としてお役立てください。このシナリオの次の図を検討してみましょう。

Web アプリケーションへのサインオンの概要

上の図を念頭に置いて、さまざまなコンポーネントについての次の情報を理解してください。

  • Azure AD は ID プロバイダーであり、組織のディレクトリに存在するユーザーとアプリケーションの ID の検証と、そのユーザーとアプリケーションが正常に認証されたときのセキュリティ トークンの最終的な発行を行います。

  • 認証を Azure AD に委託するアプリケーションは、Azure AD に登録されている必要があります。Azure AD は、ディレクトリに登録されたアプリを一意に識別します。

  • 開発者は、オープン ソース Azure AD 認証ライブラリを使用して、プロトコルの詳細を操作して認証を容易にできます。詳細については、「Azure Active Directory Authentication Libraries」を参照してください。

  • ユーザーが認証されると、アプリケーションは、意図した相手への認証が成功したことを確認するためにユーザーのセキュリティ トークンを検証する必要があります。開発者は、提供された認証ライブラリを使用して、JSON Web トークン (JWT) や SAML 2.0 などの Azure AD の任意のトークンの検証を取り扱うことができます。手動で検証を実行する場合は、「JWT トークン ハンドラー」ドキュメントを参照してください。

    noteメモ
    Azure AD は、公開キーの暗号化を使用して、トークンに署名し、トークンが有効であることを検証します。常に最新のキーで更新するための、アプリケーションに必要なロジックの詳細については、「Important Information About Signing Key Rollover in Azure AD」を参照してください。

  • 認証プロセスの要求および応答のフローは、OAuth 2.0、OpenID Connect、WS-Federation、SAML 2.0 などの、使用される認証プロトコルによって決定されます。これらのプロトコルについては、「Azure Active Directory の認証プロトコル」トピックと後のセクションで詳細を説明します。

Important重要
Azure AD は、JWT として表されるベアラー トークンを含む、ベアラー トークンを幅広く使用する OAuth 2.0 と OpenID Connect の規格をサポートします。ベアラー トークンは、保護されたリソースへの "ベアラー" のアクセスを許可する、簡易的なセキュリティ トークンです。この意味で、"ベアラー" はトークンを提示する任意の利用者を表します。利用者は、ベアラー トークンを受け取るために、最初に Azure AD で認証される必要がありますが、転送中やストレージ内でトークンを保護するための必要な手順が取られていない場合、別の利用者によって意図せず傍受されたり使用されたりする可能性があります。一部のセキュリティ トークンには、許可されていない相手の使用を防止するための組み込みメカニズムがありますが、ベアラー トークンにはこのメカニズムがないため、トランスポート層セキュリティ (HTTPS) などのセキュリティで保護されたチャネルを経由して転送される必要があります。ベアラー トークンが暗号化されずに転送された場合、悪意のある利用者が中間者攻撃によってトークンを取得して、保護されたリソースに無許可でアクセスする可能性があります。後で使用するためにベアラー トークンを格納またはキャッシュするときも、同じセキュリティ原則が適用されます。アプリケーションが常にベアラー トークンをセキュリティで保護された方法で転送および格納するようにしてください。ベアラー トークンのセキュリティの考慮事項の詳細については、RFC 6750 セクション 5 を参照してください。

基本の説明が終了しました。Azure AD でのプロビジョニングの動作と Azure AD がサポートする一般的なシナリオを理解するには、後のセクションを参照してください。

Azure AD に認証を委託するすべてのアプリケーションを、ディレクトリに登録する必要があります。このステップでは、配置されている URL、認証後の返信の送信先の URL、アプリケーションを識別するための URI などを含む、アプリケーションについての情報を Azure AD に通知する必要があります。この情報が必要な理由は、主に次のとおりです。

  • Azure AD は、サインオンの処理やトークンの交換の際に、アプリケーションとの通信のコーディネートを必要とします。その例を以下に示します。

    • アプリケーション ID の URI: アプリケーションの識別子です。この値は、呼び出し元が要求しているのがどのアプリケーションのトークンかを示すために、認証中に Azure AD に送信されます。また、この値は、目的とするターゲットをアプリケーションが把握できるように、トークンにも含まれます。

    • 応答 URL とリダイレクト URI: Web API または Web アプリケーションの場合、応答 URL は、Azure AD が、認証が正常に行われたときのトークンなどの認証の応答を送信する宛先です。ネイティブ アプリケーションの場合、リダイレクト URI は、Azure AD が OAuth 2.0 要求でユーザー エージェントをリダイレクトする宛先の一意の識別子です。

    • クライアント ID: アプリケーションを登録するときに Azure AD で生成されるアプリケーションの ID です。認証コードまたはトークンを要求すると、クライアント ID およびキーが、認証中に Azure AD に送信されます。

    • キー: Web API を呼び出すために Azure AD を認証するときにクライアント ID と共に送信されるキーです。

  • Azure AD では、ディレクトリ データや組織の他のアプリケーションなどにアクセスするための権限をアプリケーションに付与する必要があります。

Azure AD と開発および統合される可能性がある 2 つのアプリケーションのカテゴリがあることを理解すると、プロビジョニングが明確になります。

  • シングル テナント アプリケーション: シングル テナント アプリケーションは、1 つの組織で使用されることを目的としています。これらは通常、エンタープライズ開発者によって作成された基幹業務 (LOB) アプリケーションです。シングル テナント アプリケーションは、1 つのディレクトリのユーザーのみによってアクセスされる必要があり、結果として、1 つのディレクトリのみでプロビジョニングされる必要があります。これらのアプリケーションは一般的に、組織の開発者によって登録されます。

  • マルチテナント アプリケーション: マルチテナント アプリケーションは、1 つの組織のみではなく、多くの組織で使用されることを目的としています。これらは通常、独立系ソフトウェア ベンダー (ISV) によって作成された、サービスとしてのソフトウェア (SaaS) アプリケーションです。マルチテナント アプリケーションは、使用される各ディレクトリでプロビジョニングされる必要があります。これらを登録するには、ユーザーまたは管理者の同意が必要です。この同意プロセスは、アプリケーションがディレクトリに登録されて Graph API または別の Web API へのアクセスが許可されたときに開始されます。別の組織のユーザーまたは管理者がアプリケーションを使用するためにサインアップすると、アプリケーションで必要な権限を示すダイアログが表示されます。ユーザーまたは管理者はその後にアプリケーションに同意できます。これによって、アプリケーションは、前に説明したデータへのアクセスが許可され、最終的にディレクトリに登録されます。詳細については、「Overview of the Consent Framework (同意フレームワークの概要)」を参照してください。

シングル テナント アプリケーションではなく、マルチテナント アプリケーションを開発する場合、考慮事項が多くなります。たとえば、アプリケーションを複数のディレクトリでユーザーが使用できるようにしている場合、ユーザーが位置するテナントを決定するメカニズムが必要です。シングル テナント アプリケーションは、ユーザーの独自のディレクトリを検出する必要があるだけですが、マルチテナント アプリケーションは Azure AD のすべてのディレクトリで特定のユーザーを識別する必要があります。このタスクを実行するために、Azure AD では、テナント固有のエンドポイントの代わりに、マルチテナント アプリケーションがサインイン要求を送ることができる共通の認証エンドポイントが提供されています。テナント固有のエンドポイントが https://login.windows.net/contoso.onmicrosoft.com になる場合があるのに対して、このエンドポイントは Azure AD のすべてのディレクトリで https://login.windows.net/common です。サインイン、サインアウト、またはトークンの検証中に、マルチテナントを処理するためのロジックが必要となるため、共通のエンドポイントは、アプリケーションの開発時に特に考慮が必要な重要な問題です。

シングル テナント アプリケーションを現在開発中で、このアプリケーションを多くの組織で使用可能にする必要がある場合は、マルチテナントに対応できるように、アプリケーションとその構成を Azure AD で容易に変更できます。また、Azure AD は、シングル テナントとマルチテナント アプリケーションのどちらの認証を提供するとしても、すべてのディレクトリのすべてのトークンに同じ署名キーを使用します。

このドキュメントに記載されている各シナリオには、プロビジョニング要件を説明するサブセクションが含まれます。Azure AD でのアプリケーションのプロビジョニングと、シングル テナント アプリケーションとマルチテナント アプリケーションの相違点の詳細については、「Adding, Updating, and Removing an Application」を参照してください。Azure AD の共通のアプリケーション シナリオを理解するには、以降の記事をご覧ください。

このドキュメントに記載されている各シナリオは、さまざまな言語およびプラットフォームを使用して開発できます。完全なコード サンプルが、それぞれ GitHub で入手可能です。また、エンド ツー エンドのシナリオの特定の部分やセグメントがアプリケーションに必要であれば、ほとんどの場合、その機能を独立して追加できます。たとえば、Web API を呼び出すネイティブ アプリケーションがある場合、Web API も呼び出す Web アプリケーションを容易に追加できます。次の図は、これらのシナリオとアプリケーションの種類、さまざまなコンポーネントを追加する方法を示します。

アプリケーションの種類とシナリオ

Azure AD によってサポートされる 4 つの主要なアプリケーション シナリオは、次のとおりです。

このセクションでは、Web ブラウザーのユーザーを Web アプリケーションに対して認証するアプリケーションについて説明します。このシナリオでは、Web アプリケーションによって、ユーザーのブラウザー上でユーザーが Azure AD にサインインするように操作します。Azure AD はユーザーのブラウザーにサインイン応答を返します。この応答のセキュリティ トークン内に、ユーザーに関するクレームが含まれています。このシナリオは、WS-Federation、SAML 2.0、および OpenID Connect プロトコルを使用したサインオンをサポートします。

  1. ユーザーが Web アプリケーションにアクセスしたとき、サインインする必要がある場合には、サインイン要求によって Azure AD の認証エンドポイントにリダイレクトされます。

  2. ユーザーはサインイン ページでサインインします。

  3. 認証が正常に行われた場合、Azure AD は認証トークンを作成し、Azure の管理ポータルで構成されたアプリケーションの応答 URL にサインイン応答を返します。実稼働アプリケーションでは、この応答 URL は HTTPS である必要があります。返されたトークンには、ユーザーに関するクレームと、トークンを検証するためにアプリケーションによって要求された Azure AD についてのクレームが含まれます。

  4. アプリケーションは、Azure AD のフェデレーション メタデータ ドキュメントから取得できる公開署名キーと発行者の情報を使用して、トークンを検証します。アプリケーションがトークンを検証した後に、Azure AD はユーザーとの新しいセッションを開始します。このセッションにより、ユーザーは有効期限が切れるまでアプリケーションにアクセスできます。

Web ブラウザー対 Web アプリケーションのシナリオのコード サンプルを参照してください。また、常に新しいサンプルが追加されるため、忘れずに確認してください。Web Browser to Web Application

  • シングル テナント:自分の組織のみのためのアプリケーションを構築している場合、Azure の管理ポータルを使用して、そのアプリケーションを会社のディレクトリに登録する必要があります。

  • マルチテナント:組織の外部のユーザーが使用できるアプリケーションを構築している場合、そのアプリケーションを会社のディレクトリに登録する必要があります。ただし、アプリケーションを使用する各会社のディレクトリにも登録する必要があります。アプリケーションをディレクトリで使用可能にするには、ユーザーのサインアップ プロセスを含めて、ユーザーがアプリケーションに同意できるようにします。ユーザーがアプリケーションにサインアップするときに、アプリケーションが必要とする権限と、同意のオプションを示すダイアログがユーザーに表示されます。必要な権限に応じて、他の組織の管理者が同意を要求される場合があります。ユーザーまたは管理者が同意すると、アプリケーションがディレクトリに登録されます。詳細については、「Adding, Updating, and Removing an Application」を参照してください。

ユーザーのセッションは、Azure AD によって発行されたトークンの有効期限が切れたときに、有効期限が切れます。非アクティブ期間に基づいてユーザーをサインアウトするなど、必要に応じてアプリケーションでこの期間を短縮できます。セッションの有効期間が終了すると、ユーザーは再度サインインするように求められます。

このセクションでは、ユーザーに代わって Web API を呼び出すネイティブ アプリケーションについて説明します。このシナリオは、OAuth 2.0 の仕様のセクション 4.1 の内容に従って、パブリック クライアントによる OAuth 2.0 認証コード許可タイプに基づいて作成されています。ネイティブ アプリケーションは、OAuth 2.0 プロトコルを使用してユーザーのアクセス トークンを取得します。その後、このアクセス トークンを Web API への要求に含めて送信します。Web API によってユーザーが認証され、目的のリソースが返されます。

AD 認証ライブラリを使用している場合、ブラウザー ポップアップ、トークンのキャッシュ、トークンの更新の処理など、次に説明するほとんどのプロトコルの詳細が自動的に処理されます。

  1. ブラウザー ポップアップを使用して、ネイティブ アプリケーションは Azure AD の認証エンドポイントを要求します。この要求には、クライアント ID と、管理ポータルで表示されるネイティブ アプリケーションのリダイレクト URI、および Web API のアプリケーション ID の URI が含まれます。ユーザーがサインインしていない場合は、再度サインインするように求められます。

  2. Azure AD はユーザーを認証します。これがマルチテナント アプリケーションであり、アプリケーションを使用するために同意が必要な場合、まだ同意していないユーザーは同意するように求められます。同意した後、正常に認証されると、Azure AD がクライアント アプリケーションのリダイレクト URI に認証コード応答を発行します。

  3. Azure AD がリダイレクト URI に認証コード応答を発行すると、クライアント アプリケーションはブラウザーのインタラクションを停止し、応答から認証コードを抽出します。この認証コードを使用して、クライアント アプリケーションは、認証コード、クライアント アプリケーションについての詳細 (クライアント ID およびリダイレクト URI)、および目的のリソース (Web API のアプリケーション ID の URI) を含む Azure AD のトークン エンドポイントに要求を送信します。

  4. 認証コードと、クライアント アプリケーションおよび Web API に関する情報は、Azure AD によって検証されます。検証が正常に行われると、Azure AD はトークンを 2 つ返します。それが、JWT アクセス トークンと JWT 更新トークンです。Azure AD はまた、表示名やテナント ID などの、ユーザーに関する基本的な情報を返します。

  5. クライアント アプリケーションは、返された JWT アクセス トークンを HTTPS 経由で使用して、要求の承認ヘッダーに "Bearer" が指定されている JWT 文字列を Web API に追加します。Web API はその後に JWT トークンを検証します。検証が正常に行われると、目的のリソースが返されます。

  6. アクセス トークンの有効期限が切れると、クライアント アプリケーションは、ユーザーを再度認証する必要があることを示すエラーを受信します。アプリケーションが有効な更新トークンを保有している場合、ユーザーに再度サインインを求めることなく、その更新トークンを新しいアクセス トークンの取得に使用できます。更新トークンの有効期限が切れると、ユーザーは再度アプリケーションによって対話形式で認証される必要があります。

    noteメモ
    Azure AD によって発行された更新トークンは、複数のリソースへのアクセスに使用できます。たとえば、2 つの Web API を呼び出す権限を持つクライアント アプリケーションを所有している場合、更新トークンは、他の Web API へのアクセス トークンを取得するために使用することもできます。

ネイティブ アプリケーション対 Web API のシナリオのコード サンプルを参照してください。また、常に新しいサンプルが追加されるため、忘れずに確認してください。Native Application to Web API

  • シングル テナント:ネイティブ クライアント アプリケーションと Web API のいずれも、Azure AD の同じディレクトリに登録する必要があります。権限のセットを公開するように Web API を構成し、その権限を使用してネイティブ アプリケーションによるリソースへのアクセスを制限することができます。クライアント アプリケーションはその後に、Azure の管理ポータルの [他のアプリケーションに対するアクセス許可] ボックスの一覧から目的の権限を選択します。

  • マルチテナント: 第 1 に、このネイティブ アプリケーションは、これまで開発者または公開元のディレクトリにのみ登録されていました。第 2 に、このネイティブ アプリケーションは利用する必要がある権限を示すように構成されています。宛先ディレクトリのユーザーまたは管理者がアプリケーションを組織で利用できるように同意するときに、必要な権限のリストがダイアログに表示されます。一部のアプリケーションではユーザーレベルの権限のみが要求されますが、これについては組織内の任意のユーザーが同意することができます。その他のアプリケーションでは管理者レベルの権限が要求され、組織内のユーザーが同意することはできません。ディレクトリ管理者のみが、このレベルの権限を必要とするアプリケーションに同意することができます。ユーザーまたは管理者が同意すると、その Web アプリケーションのみがディレクトリに登録されます。詳細については、「Adding, Updating, and Removing an Application」を参照してください。

ネイティブ アプリケーションは、JWT アクセス トークンを取得するために認証コードを使用するとき、JWT 更新トークンも受信します。アクセス トークンの有効期限が切れると、更新トークンをユーザーの再認証のために使用でき、再度サインインする必要はありません。この更新トークンはその後、ユーザーを認証するために使用されます。これにより、新しいアクセス トークンと更新トークンが得られます。

このセクションでは、Web API からリソースを取得する必要がある Web アプリケーションについて説明します。このシナリオでは、Web アプリケーションが Web API を認証および呼び出すために使用できる 2 種類の ID を取り扱います。それが、アプリケーション ID と委任ユーザー ID です。このシナリオではこの種類のアプリケーション ID について、OAuth 2.0 クライアント資格情報を使用し、アプリケーションとして認証して Web API にアクセスすることを許可します。アプリケーション ID を使用する場合、Web API はユーザーに関する情報を受信しないため、Web API は Web アプリケーションが呼び出していることのみを検出できます。アプリケーションがユーザーに関する情報を受信しても、その情報はアプリケーション プロトコル経由で送信され、Azure AD によって署名されません。Web API は、Web アプリケーションがユーザーを認証したことを信頼します。したがって、このパターンは trusted subsystem と呼ばれます。

委任ユーザー ID の種別では、シナリオを 2 種類の方法で実行できます。それが、OpenID Connect と、秘密のクライアントを使用した OAuth 2.0 認証コード付与です。Web アプリケーションはユーザー用のアクセス トークンを取得します。これによって、ユーザーが Web アプリケーションで正常に認証されたことと、Web アプリケーションが Web API を呼び出すために委任ユーザー ID を取得できたことを Web API に証明します。このアクセス トークンが Web API への要求に含めて送信されます。Web API によってユーザーが認証され、目的のリソースが返されます。

アプリケーション ID と委任ユーザー ID の両方の種別が、次のフローで説明されています。両者の主な相違点は、委任ユーザー ID は、ユーザーがサインインして Web API にアクセス可能にするために、最初に認証コードを取得する必要がある点です。

OAuth 2.0 クライアント資格情報が付与されたアプリケーション ID

  1. ユーザーが、Web アプリケーションの Azure AD にサインインしています (上の「Web ブラウザー対 Web アプリケーシ」セクションを参照してください)。

  2. Web アプリケーションは、Web API を認証し、目的のリソースを取得できるように、アクセス トークンを取得する必要があります。Azure AD のトークン エンドポイントを要求して、資格情報、クライアント ID、および Web API のアプリケーション ID の URI を提供します。

  3. Azure AD はアプリケーションを認証し、Web API を呼び出すために使用される JWT アクセス トークンを返します。

  4. Web アプリケーションは、返された JWT アクセス トークンを HTTPS 経由で使用して、要求の承認ヘッダーに "Bearer" が指定されている JWT 文字列を Web API に追加します。Web API はその後に JWT トークンを検証します。検証が正常に行われると、目的のリソースが返されます。

委任ユーザー ID と OpenID Connect

  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 はトークンを 2 つ返します。それが、JWT アクセス トークンと JWT 更新トークンです。

  4. Web アプリケーションは、返された JWT アクセス トークンを HTTPS 経由で使用して、要求の承認ヘッダーに "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 を呼び出すことに同意していない場合、同意する必要があります。アプリケーションには必要な権限が表示されます。そのいずれかが管理者レベル権限である場合は、ディレクトリの通常のユーザーが同意することはできません。アプリケーションには必要な権限が既に与えられているため、この同意プロセスは、シングル テナント アプリケーションではなくマルチテナント アプリケーションのみに適用されます。

  4. ユーザーが同意した後に、Web アプリケーションは、アクセス トークンを取得する必要がある認証コードを受信します。

  5. Azure AD によって発行された認証コードを使用して、Web アプリケーションは、認証コード、クライアント アプリケーションについての詳細 (クライアント ID およびリダイレクト URI)、および目的のリソース (Web API のアプリケーション ID の URI) を含む Azure AD のトークン エンドポイントに要求を送信します。

  6. 認証コードと Web アプリケーションおよび Web API に関する情報は、Azure AD によって検証されます。検証が正常に行われると、Azure AD はトークンを 2 つ返します。それが、JWT アクセス トークンと JWT 更新トークンです。

  7. Web アプリケーションは、返された JWT アクセス トークンを HTTPS 経由で使用して、要求の承認ヘッダーに "Bearer" が指定されている JWT 文字列を Web API に追加します。Web API はその後に JWT トークンを検証します。検証が正常に行われると、目的のリソースが返されます。

Web アプリケーション対 Web API のシナリオのコード サンプルを参照してください。また、常に新しいサンプルが追加されるため、忘れずに確認してください。Web Application to Web API

  • シングル テナント:アプリケーション ID と委任ユーザー ID の両方の例で、Web アプリケーションおよび Web API が Azure AD の同じディレクトリに登録されている必要があります。リソースへの Web アプリケーションのアクセスを制限するために使用される権限のセットを公開するために、Web API を構成できます。委任ユーザー ID が使用されている場合、Web アプリケーションは、Azure の管理ポータルの [他のアプリケーションに対するアクセス許可] ボックスの一覧から目的の権限を選択する必要があります。アプリケーション ID 種別が使用されている場合、このステップは必要ありません。

  • マルチテナント:最初に、機能する必要がある権限を示すために、Web アプリケーションが構成されます。宛先ディレクトリのユーザーまたは管理者がアプリケーションを組織で利用できるように同意するときに、必要な権限のリストがダイアログに表示されます。一部のアプリケーションではユーザーレベルの権限のみが要求されますが、これについては組織内の任意のユーザーが同意することができます。その他のアプリケーションでは管理者レベルの権限が要求され、組織内のユーザーが同意することはできません。ディレクトリ管理者のみが、このレベルの権限を必要とするアプリケーションに同意することができます。ユーザーまたは管理者が同意すると、Web アプリケーションおよび Web API の両方がディレクトリに登録されます。

Web アプリケーションは、JWT アクセス トークンを取得するために認証コードを使用するとき、JWT 更新トークンも受信します。アクセス トークンの有効期限が切れると、更新トークンをユーザーの再認証のために使用でき、再度サインインする必要はありません。この更新トークンはその後、ユーザーを認証するために使用されます。これにより、新しいアクセス トークンと更新トークンが得られます。

このセクションでは、Web API からリソースを取得する必要があるデーモンまたはサーバー アプリケーションについて説明します。このセクションに適用される 2 つのサブシナリオがあります。1 つは、OAuth 2.0 クライアント資格情報許可タイプに基づいて構築された、Web API を呼び出す必要があるデーモンです。もう 1 つは、OAuth 2.0 On-Behalf-Of ドラフト仕様に基づいて構築された、Web API を呼び出す必要があるサーバー アプリケーション (Web API など) です。

デーモン アプリケーションが Web API を呼び出す必要があるシナリオでは、理解が必要な重要な項目がいくつかあります。最初に、ユーザー インタラクションはデーモン アプリケーションでは不可能です。デーモン アプリケーションは、独自 ID を持つアプリケーションを必要とします。デーモン アプリケーションの例が、バッチ ジョブ、つまりバックグラウンドで実行されるオペレーティング システム サービスです。この種別のアプリケーションは、アプリケーション ID を使用し、クライアント ID、資格情報 (パスワードまたは証明書)、および Azure AD に対するアプリケーション ID の URI を示して、アクセス トークンを要求します。認証が正常に行われると、デーモンは Azure AD からアクセス トークンを受信します。これは、その後に、Web API を呼び出すために使用されます。

サーバー アプリケーションが Web API を呼び出す必要があるシナリオでは、サンプルを使用するとわかりやすくなります。ネイティブ アプリケーションでユーザーが認証されていて、このネイティブ アプリケーションが Web API を呼び出す必要があるとします。Azure AD は、Web API を呼び出すための JWT アクセス トークンを発行します。Web API が別の下流 Web API を呼び出す必要がある場合、"代理" フローを使用してユーザーの ID を委任し、第 2 層の Web API で認証できます。

OAuth 2.0 クライアント資格情報が付与されたアプリケーション ID

  1. 最初に、サーバー アプリケーションは、対話形式のサインオン ダイアログなどで人と対話することなく、Azure AD で自身を認証する必要があります。Azure AD のトークン エンドポイントを要求して、資格情報、クライアント ID、およびアプリケーション ID の URI を提供します。

  2. Azure AD はアプリケーションを認証し、Web API を呼び出すために使用される JWT アクセス トークンを返します。

  3. Web アプリケーションは、返された JWT アクセス トークンを HTTPS 経由で使用して、要求の承認ヘッダーに "Bearer" が指定されている JWT 文字列を Web API に追加します。Web API はその後に JWT トークンを検証します。検証が正常に行われると、目的のリソースが返されます。

OAuth 2.0 On-Behalf-Of ドラフト仕様による委任ユーザー ID

次に説明するフローは、ユーザーが別のアプリケーション (ネイティブ アプリケーションなど) で認証されていることと、第 1 層の Web API に対するアクセス トークンを取得するためにユーザー ID が使用されていることを前提とします。

  1. ネイティブ アプリケーションは、第 1 層の Web API にアクセス トークンを送信します。

  2. 第 1 層の Web API は、Azure AD のトークン エンドポイントに要求を送信し、ユーザーのアクセス トークンだけでなく、クライアント ID および資格情報を提供します。また、この要求は、Web API が、下流 Web API を呼び出すために、元のユーザーの代わりに新しいトークンを要求していることを示す on_behalf_of パラメーターと共に送信されます。

  3. Azure AD は、第 1 層の Web API が第 2 層の Web API にアクセスする権限を持つことを検証し、要求が、第 1 層の Web API に JWT アクセス トークンおよび JWT 更新トークンを返すことを検証します。

  4. 第 1 層の Web API はその後、HTTPS 経由で、要求の承認ヘッダーにトークン文字列を追加して、第 2 層の Web API を呼び出します。第 1 層の Web API は、アクセス トークンと更新トークンが有効な限り、第 2 層の Web API を引き続き呼び出すことができます。

デーモンまたはサーバー アプリケーション対 Web API のシナリオのコード サンプルを参照してください。また、常に新しいサンプルが追加されるため、忘れずに確認してください。Server or Daemon Application to Web API

  • シングル テナント:アプリケーション ID と委任ユーザー ID の両方の例で、デーモンまたはサーバー アプリケーションが Azure AD の同じディレクトリに登録されている必要があります。リソースへのデーモンまたはサーバー アプリケーションによるアクセスを制限するために使用される権限のセットを公開するために、Web API を構成できます。委任ユーザー ID が使用されている場合、サーバー アプリケーションは、Azure の管理ポータルの [他のアプリケーションに対するアクセス許可] ボックスの一覧から目的の権限を選択する必要があります。アプリケーション ID 種別が使用されている場合、このステップは必要ありません。

  • マルチテナント:最初に、機能する必要がある権限を示すために、デーモンまたはサーバー アプリケーションが構成されます。宛先ディレクトリのユーザーまたは管理者がアプリケーションを組織で利用できるように同意するときに、必要な権限のリストがダイアログに表示されます。一部のアプリケーションではユーザーレベルの権限のみが要求されますが、これについては組織内の任意のユーザーが同意することができます。その他のアプリケーションでは管理者レベルの権限が要求され、組織内のユーザーが同意することはできません。ディレクトリ管理者のみが、このレベルの権限を必要とするアプリケーションに同意することができます。ユーザーまたは管理者が同意すると、両方の Web API がディレクトリに登録されます。

最初のアプリケーションは、JWT アクセス トークンを取得するために認証コードを使用するとき、JWT 更新トークンも受信します。アクセス トークンの有効期限が切れると、更新トークンをユーザーの再認証のために使用でき、資格情報を求められることはありません。この更新トークンはその後、ユーザーを認証するために使用されます。これにより、新しいアクセス トークンと更新トークンが得られます。

関連項目

この情報は役に立ちましたか。
(残り 1500 文字)
フィードバックをいただき、ありがとうございました
表示:
© 2014 Microsoft