ネイティブ アプリ

ネイティブ アプリは、ユーザーの代わりに Web API を呼び出すアプリケーションです。 このシナリオは、OAuth 2.0 仕様のセクション 4.1 で説明されているように、パブリック クライアントを使用した OAuth 2.0 承認コード許可の種類に基づいて構築されています。 ネイティブ アプリケーションは、OAuth 2.0 プロトコルを使用してユーザーのアクセス トークンを取得します。 このアクセス トークンは、要求で Web API に送信され、ユーザーを承認し、目的のリソースを返します。

ダイアグラム

プロトコル フロー

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

1. ブラウザーのポップアップを使用して、ネイティブ アプリケーションは Azure AD の承認エンドポイントに要求を行います。 この要求には、Azure portal に示されているネイティブ アプリケーションのアプリケーション 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 は JWT アクセス トークンと JWT 更新トークンの 2 つのトークンを返します。 さらに、Azure AD は、ユーザーの表示名やテナント ID など、ユーザーに関する基本情報を返します。
5. HTTPS 経由で、クライアント アプリケーションは返された JWT アクセス トークンを使用して、要求の Authorization ヘッダーに "Bearer" という指定の JWT 文字列を Web API に追加します。 その後、Web API は JWT トークンを検証し、検証が成功した場合は目的のリソースを返します。
6. アクセス トークンの有効期限が切れると、クライアント アプリケーションは、ユーザーが再度認証する必要があることを示すエラーを受け取ります。 アプリケーションに有効な更新トークンがある場合は、ユーザーに再度サインインを求めることなく、新しいアクセス トークンを取得するために使用できます。 更新トークンの有効期限が切れた場合、アプリケーションはユーザーをもう一度対話形式で認証する必要があります。

コード サンプル

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

アプリの登録

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

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

トークンの有効期限

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

次のステップ

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