次の方法で共有


Web API を呼び出すモバイル アプリを構成する

適用対象: 次の内容が従業員テナントに適用されることを示す白いチェック マーク記号が付いた緑の円。 ワークフォース テナント (詳細)

アプリケーションを作成した後、アプリ登録パラメーターを使用してコードを構成する方法を確認します。 モバイル アプリケーションでは、作成フレームワークへの適合に関連するいくつかの複雑さが伴います。

[前提条件]

  • アクティブなサブスクリプションを持つ Azure アカウント。 無料でアカウントを作成できます。 このアカウントには、アプリケーションを管理するためのアクセス許可が必要です。 アプリケーションを登録するために必要な次のロールのいずれかを使用します。
    • アプリケーション管理者
    • アプリケーション開発者
  • この組織のディレクトリ内のアカウント専用に構成された Microsoft Entra 管理センターに新しいアプリを登録します。 詳細については、「 アプリケーションの登録 」を参照してください。 後で使用するために、アプリケーション の [概要 ] ページから次の値を記録します。
    • アプリケーション (クライアント) ID
    • ディレクトリ (テナント) ID

プラットフォーム リダイレクト URI を追加する

アプリの登録にアプリの種類を指定するには、次の手順に従います。

  1. [管理] で、 [認証]>[プラットフォームの追加]>[iOS/macOS] の順に選択します。
  2. バンドル ID を入力した後、 [構成] を選択します。 リダイレクト URI が計算されます。

リダイレクト URI を手動で構成する場合は、アプリケーション マニフェストを介して行えます。 マニフェストの推奨される形式は次のとおりです。

  • iOSの場合: msauth.<BUNDLE_ID>://auth
    • たとえば、「msauth.com.yourcompany.appName://auth」と入力します。
  • アンドロイドの場合: msauth://<PACKAGE_NAME>/<SIGNATURE_HASH>
    • Android の署名のハッシュは、KeyTool コマンドを通じて、リリース キーまたはデバッグ キーを使用して生成できます。

パブリック クライアント フローを有効にする

アプリでユーザー名とパスワード認証のみを使用する場合は、アプリケーションのリダイレクト URI を登録する必要はありません。 このフローによって、Microsoft ID プラットフォームへのラウンド トリップが実行されます。 アプリケーションが特定の URI でコールバックされることはありません。 ただし、パブリック クライアント フローを有効にする必要があります。

アプリをパブリック クライアントとして識別するには、次の手順に従います。

  1. [管理] で、 [認証] を選択します。

  2. [詳細設定] で、[パブリック クライアント フローを許可する] に対して [はい] を選択します。

  3. [保存] を選択して変更を保存します。

モバイル アプリをサポートする Microsoft ライブラリ

次の Microsoft ライブラリはモバイル アプリをサポートしています。

プラットフォーム プロジェクト
GitHub
Package 取得
started
ユーザーのサインイン Web API へのアクセス 一般提供 (GA) または
パブリック プレビュー1
Android (Java) MSAL アンドロイド MSAL クイック スタート ライブラリでは、ユーザー サインインの ID トークンを要求できます。 ライブラリでは、保護された Web API のアクセス トークンを要求できます。 GA
Android (Kotlin) MSAL アンドロイド MSAL ライブラリでは、ユーザー サインインの ID トークンを要求できます。 ライブラリでは、保護された Web API のアクセス トークンを要求できます。 GA
iOS (Swift/Obj-C) iOS および macOS 用の MSAL MSAL チュートリアル ライブラリでは、ユーザー サインインの ID トークンを要求できます。 ライブラリでは、保護された Web API のアクセス トークンを要求できます。 GA

1オンライン サービスのユニバーサル ライセンス条項は、パブリック プレビューのライブラリに適用されます。

アプリケーションをインスタンス化する

Android

モバイル アプリケーションでは PublicClientApplication クラスが使用されます。 これをインスタンス化する方法を次に示します。

PublicClientApplication sampleApp = new PublicClientApplication(
                    this.getApplicationContext(),
                    R.raw.auth_config);

iOS

iOS 上のモバイル アプリケーションは、MSALPublicClientApplication クラスをインスタンス化する必要があります。 このクラスをインスタンス化するには、次のコードを使用します。

NSError *msalError = nil;

MSALPublicClientApplicationConfig *config = [[MSALPublicClientApplicationConfig alloc] initWithClientId:@"<your-client-id-here>"];
MSALPublicClientApplication *application = [[MSALPublicClientApplication alloc] initWithConfiguration:config error:&msalError];
let config = MSALPublicClientApplicationConfig(clientId: "<your-client-id-here>")
if let application = try? MSALPublicClientApplication(configuration: config){ /* Use application */}

追加の MSALPublicClientApplicationConfig プロパティで、既定の機関のオーバーライド、リダイレクト URI の指定、または MSAL トークンのキャッシュ動作の変更を行うことができます。

UWP

このセクションでは、UWP アプリのアプリケーションをインスタンス化する方法について説明します。

アプリケーションをインスタンス化する

UWP では、アプリケーションをインスタンス化する最も簡単な方法は、次のコードを使用することです。 このコードの ClientId は、登録済みアプリの GUID です。

var app = PublicClientApplicationBuilder.Create(clientId)
                                        .Build();

追加の With<Parameter> メソッドを使用して、親 UI の設定、既定の機関のオーバーライド、クライアント名とバージョンの指定 (テレメトリ用)、リダイレクト URI の指定、および使用する HTTP ファクトリの指定を実行します。 たとえば、HTTP ファクトリを使用して、プロキシの処理とテレメトリとログの指定を行います。

次のセクションで、アプリケーションのインスタンス化について詳しく説明します。

親 UI、ウィンドウ、またはアクティビティを指定する

Android では、対話型認証を行う前に親アクティビティを渡します。 iOS でブローカーを使用する場合は、ViewController を渡します。 UWP の場合と同じように、親ウィンドウを渡すことができます。 トークンを取得するときに、それを渡します。 ただし、アプリを作成するときに、コールバックを UIParent を返すデリゲートとして指定することもできます。

IPublicClientApplication application = PublicClientApplicationBuilder.Create(clientId)
  .ParentActivityOrWindowFunc(() => parentUi)
  .Build();

Android では、CurrentActivityPlugin の使用をお勧めします。 結果の PublicClientApplication ビルダー コードは、次の例のようになります。

// Requires MSAL.NET 4.2 or above
var pca = PublicClientApplicationBuilder
  .Create("<your-client-id-here>")
  .WithParentActivityOrWindow(() => CrossCurrentActivity.Current)
  .Build();
他のアプリ ビルド パラメーターを見つける

PublicClientApplicationBuilder で使用できるすべてのメソッドの一覧については、メソッドの一覧を参照してください。

PublicClientApplicationOptions で公開されるすべてのオプションの説明については、リファレンス ドキュメントを参照してください。

iOS と macOS 用の MSAL のタスク

iOS と macOS 用の MSAL を使用する場合は、次のタスクが必要です。

UWP のタスク

UWP では企業ネットワークを使用できます。 次のセクションで、企業のシナリオで完了する必要があるタスクについて説明します。

詳細については、MSAL.NET での UWP 固有の考慮事項に関する記事を参照してください。

ブローカーを使用するようにアプリケーションを構成する

Android と iOS では、ブローカーによって次のことが可能になります。

  • シングル サインオン (SSO): Microsoft Entra ID に登録されているデバイスに SSO を使用できます。 SSO を使用すると、ユーザーはアプリケーションごとにサインインする必要がなくなります。
  • デバイスの識別: この設定により、Microsoft Entra デバイスに関連する条件付きアクセス ポリシーが有効になります。 認証プロセスでは、デバイスがワークプレースに参加したときに作成されたデバイス証明書が使用されます。
  • アプリケーション ID の検証: アプリケーションでは、ブローカーを呼び出すときにそのリダイレクト URL を渡します。 ブローカーによってそれが検証されます。

Android 向け MSAL に対するブローカーの有効化

Android でブローカーを有効にする方法の詳細については、「Android のブローカー認証」を参照してください。

iOS および macOS 用の MSAL に対するブローカーの有効化

iOS および macOS 用の MSAL を使用する Microsoft Entra シナリオでは、ブローカー認証が既定で有効化されています。

以降のセクションでは、iOS および macOS のブローカー認証サポート用にアプリケーションを構成する手順について説明します。 この 2 つの手順セットでは、一部の手順が異なります。

iOS および macOS 用の MSAL のブローカー認証

Microsoft Entra シナリオでは、ブローカー認証が既定で有効化されています。

手順 1:コールバックを処理するように AppDelegate を更新する

iOS および macOS 用の MSAL でブローカーが呼び出されると、ブローカーは openURL メソッドを使用してアプリケーションにコールバックします。 MSAL がブローカーからの応答を待っているため、アプリケーションが協力して MSAL をコールバックする必要があります。 次のコード例に示すように、メソッドをオーバーライドするように AppDelegate.m ファイルを更新することで、この機能を設定します。

- (BOOL)application:(UIApplication *)app
            openURL:(NSURL *)url
            options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options
{
    return [MSALPublicClientApplication handleMSALResponse:url
                                         sourceApplication:options[UIApplicationOpenURLOptionsSourceApplicationKey]];
}
    func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {

        guard let sourceApplication = options[UIApplication.OpenURLOptionsKey.sourceApplication] as? String else {
            return false
        }

        return MSALPublicClientApplication.handleMSALResponse(url, sourceApplication: sourceApplication)
    }

iOS 13 以降で UISceneDelegate を採用した場合は、代わりに scene:openURLContexts:UISceneDelegate に MSAL のコールバックを配置します。 MSAL handleMSALResponse:sourceApplication: の呼び出しは URL ごとに 1 回のみにする必要があります。

詳しくは、Apple のドキュメントをご覧ください。

手順 2:URL スキームを登録する

iOS および macOS 用の MSAL では、URL を使用してブローカーが呼び出され、ブローカーの応答がアプリに返されます。 ラウンド トリップを終了するには、Info.plist ファイルにアプリの URL スキームを登録します。

アプリのスキームを登録するには:

  1. カスタム URL スキームの前に msauth を付けます。

  2. バンドル ID をスキーマの末尾に追加します。 次のパターンに従います。

    $"msauth.(BundleId)"

    ここでは、BundleId によってデバイスが一意に識別されます。 たとえば、BundleIdyourcompany.xforms の場合、URL スキームは msauth.com.yourcompany.xforms になります。

    この URL スキームは、ブローカーから応答を受け取るときにアプリを一意に識別するリダイレクト URI の一部になります。 msauth.(BundleId)://auth 形式のリダイレクト URI がアプリケーションに対して登録されていることを確認してください。

    <key>CFBundleURLTypes</key>
    <array>
        <dict>
            <key>CFBundleURLSchemes</key>
            <array>
                <string>msauth.[BUNDLE_ID]</string>
            </array>
        </dict>
    </array>
    

手順 3:LSApplicationQueriesSchemes を追加する

Microsoft Authenticator アプリがインストールされている場合にその呼び出しを許可するために、LSApplicationQueriesSchemes を追加します。

アプリが Xcode 11 以降を使用してコンパイルされている場合は、msauthv3 スキームが必要です。

LSApplicationQueriesSchemes を追加する方法の例を次に示します。

<key>LSApplicationQueriesSchemes</key>
<array>
  <string>msauthv2</string>
  <string>msauthv3</string>
</array>

次のステップ

このシナリオの次のトークンを取得するに関する記事に進みます。