次の方法で共有


Microsoft Entra ID に Azure confidential ledger アプリケーションを登録する方法

この記事では、Azure Confidential Ledger アプリケーションを Microsoft ID プラットフォームに登録して、Microsoft Entra ID と統合する方法について説明します。

Microsoft ID プラットフォームは、登録済みのアプリケーションに対してのみ ID およびアクセス管理 (IAM) を実行します。 Web またはモバイル アプリのようなクライアント アプリケーション、またはクライアント アプリを支援する Web API のいずれであっても、それを登録することにより、アプリケーションと ID プロバイダー、つまり Microsoft ID プラットフォームとの間の信頼関係が確立されます。 Microsoft ID プラットフォームの詳細をご確認ください

前提条件

アプリケーションを登録する

Azure confidential ledger アプリケーションを登録すると、アプリケーションと Microsoft ID プラットフォームとの間の信頼関係が確立されます。 この信頼は一方向です。つまり、アプリは Microsoft ID プラットフォームを信頼しますが、その逆はありません。

アプリ登録を作成するには、次の手順に従います。

  1. Azure portal にサインインします。

  2. 複数のテナントにアクセスできる場合は、トップ メニューの [ディレクトリとサブスクリプション] フィルターを使用して、アプリケーションを登録するテナントに切り替えます。

  3. Microsoft Entra ID を検索して選択します。

  4. [管理][アプリの登録]>[新規登録] の順に選択します。

  5. アプリケーションの表示を入力します。 表示名は、サインイン時など、アプリケーションのユーザーがアプリを使用するときに表示されることがあります。 表示名はいつでも変更できます。また、複数のアプリの登録で同じ名前を共有できます。 ID プラットフォーム内では、表示名ではなく、アプリ登録の自動生成されたアプリケーション (クライアント) ID によってアプリが一意に識別されます。

  6. アプリケーションを使用できるユーザーを指定します。これは、"サインインの対象ユーザー" と呼ばれることもあります。

    サポートされているアカウントの種類 説明
    この組織のディレクトリ内のアカウントのみ "ご利用の" テナント内のユーザー (またはゲスト) によってのみ使用されるアプリケーションをビルドしている場合、このオプションを選択します。

    このアプリは、多くの場合、"基幹業務" (LOB) アプリケーションと呼ばれ、Microsoft ID プラットフォームの "シングルテナント" アプリケーションです。
    任意の組織のディレクトリ内のアカウント "任意" の Microsoft Entra テナント内のユーザーがアプリケーションを使用できるようにする場合は、このオプションを選択します。 このオプションは、たとえば、複数の組織に提供する目的でサービスとしてのソフトウェア (SaaS) アプリケーションをビルドしている場合に適しています。

    Microsoft ID プラットフォームでは、この種類のアプリは、"マルチテナント" アプリケーションと呼ばれます。
    任意の組織のディレクトリ内のアカウントと、個人用の Microsoft アカウント 最も広範な顧客のセットを対象とする場合は、このオプションを選択します。

    個人用 "Microsoft アカウント" を持つユーザーもサポートできる "マルチテナント" アプリケーションを登録するには、このオプションを選択します。
    個人用 Microsoft アカウント 個人用 Microsoft アカウントを持つユーザー専用のアプリケーションを構築している場合は、このオプションを選択します。 個人用 Microsoft アカウントには、Skype、Xbox、Live、Hotmail のアカウントが含まれます。
  7. [リダイレクト URI (省略可能)] には何も入力しないでください。 リダイレクト URI は、次のセクションで構成します。

  8. [登録] を選択して、初期のアプリ登録を完了します。

    [アプリケーションの登録] ペインを示す、Web ブラウザー内の Azure portal のスクリーンショット。

登録が完了すると、Azure portal に、アプリの登録の [概要] ペインが表示されます。 [アプリケーション (クライアント) ID] の値を確認します。 この値は、"クライアント ID" とも呼ばれ、Microsoft ID プラットフォーム内のアプリケーションを一意に識別します。

重要

新しいアプリの登録は、既定ではユーザーに対して非表示になっています。 ユーザーがアプリを [マイ アプリ] ページで表示するための準備を整えたら、これを有効にすることができます。 アプリを有効にするには、Azure portal で、[Microsoft Entra ID]>[エンタープライズ アプリケーション] の順に移動し、アプリを選択してください。 次に、 [プロパティ] ページで [ユーザーに表示しますか?] を [はい] に切り替えます。

アプリケーションのコード (より一般的には、アプリケーションで使用される認証ライブラリ) でも、このクライアント ID を使用します。 この ID は、ID プラットフォームから受信するセキュリティ トークンの検証過程で使用されます。

アプリの登録の [概要] ペインを示す、Web ブラウザー内の Azure portal のスクリーンショット。

リダイレクト URI を追加する

"リダイレクト URI" は、認証後に Microsoft ID プラットフォームによってユーザーのクライアントがリダイレクトされ、セキュリティ トークンが送信される場所です。

たとえば、運用 Web アプリケーションでは、多くの場合、リダイレクト URI は、アプリが実行されているパブリック エンドポイント (例: https://contoso.com/auth-response) です。 開発時には、アプリをローカルで実行するエンドポイント (例: https://127.0.0.1/auth-response または http://localhost/auth-response) も追加するのが一般的です。

登録済みのアプリケーションのリダイレクト URI を追加および変更するには、そのプラットフォーム設定を構成します。

プラットフォーム設定を構成する

リダイレクト URI など、アプリケーションの種類ごとの設定は、Azure portal の [プラットフォーム構成] で構成します。 Webシングルページ アプリケーションなどの一部のプラットフォームでは、リダイレクト URI を手動で指定する必要があります。 モバイルやデスクトップなどの他のプラットフォームでは、他の設定を構成するときに自動的に生成されるリダイレクト URI から選択できます。

ターゲットのプラットフォームまたはデバイスに基づいてアプリケーション設定を構成するには、次の手順に従います。

  1. Azure portal の [アプリの登録] で、対象のアプリケーションを選択します。

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

  3. [プラットフォーム構成][プラットフォームを追加] を選択します。

  4. [プラットフォームの構成] で、アプリケーションの種類 (プラットフォーム) のタイルを選択して、その設定を構成します。

    Azure portal の [プラットフォームの構成] ペインのスクリーンショット。

    プラットフォーム 構成設定
    Web アプリのリダイレクト URI を入力します。 この URI は、認証後に Microsoft ID プラットフォームによってユーザーのクライアントがリダイレクトされ、セキュリティ トークンが送信される場所です。

    サーバーで実行される標準の Web アプリケーションについては、このプラットフォームを選択します。
    シングルページ アプリケーション アプリのリダイレクト URI を入力します。 この URI は、認証後に Microsoft ID プラットフォームによってユーザーのクライアントがリダイレクトされ、セキュリティ トークンが送信される場所です。

    JavaScript や、Angular、Vue.js、React.js、Blazor WebAssembly などのフレームワークを使用してクライアント側 Web アプリを構築している場合は、このプラットフォームを選択します。
    iOS / macOS アプリのバンドル ID を入力します。 これは、 [ビルド設定] または Info.plist 内の Xcode で検索します。

    バンドル ID を指定すると、リダイレクト URI が自動的に生成されます。
    Android アプリのパッケージ名を入力します。 これは、AndroidManifest.xml ファイル内で検索します。 また、署名ハッシュも生成して入力します。

    これらの設定を指定すると、リダイレクト URI が自動的に生成されます。
    モバイル アプリケーションとデスクトップ アプリケーション 推奨されるリダイレクト URI のいずれかを選択します。 または、カスタム リダイレクト URI を指定します。

    埋め込みブラウザーを使用するデスクトップ アプリケーションの場合は、次を推奨します
    https://login.microsoftonline.com/common/oauth2/nativeclient

    システム ブラウザーを使用するデスクトップ アプリケーションの場合は、次を推奨します
    http://localhost

    最新の Microsoft Authentication Library (MSAL) を使用していない、またはブローカーを使用していないモバイル アプリケーションには、このプラットフォームを選択します。 また、デスクトップ アプリケーションにも、このプラットフォームを選択します。
  5. [構成する] を選択して、プラットフォームの構成を完了します。

リダイレクト URI の制限

アプリ登録に追加するリダイレクト URI の形式には、いくつかの制限があります。 これらの制限の詳細については、「リダイレクト URI (応答 URL) に関する制約と制限」を参照してください。

資格情報を追加する

資格情報は、Web API にアクセスする Confidential クライアント アプリケーションによって使用されます。 Confidential クライアントの例としては、Web アプリ、その他の Web API、またはサービス型およびデーモン型アプリケーションなどがあります。 資格情報により、アプリケーションはそれ自体として認証され、実行時にユーザーによる操作は必要ありません。

証明書とクライアント シークレット (文字列) の両方を資格情報として Confidential クライアント アプリの登録に追加できます。

[アプリの登録] の [証明書およびシークレット] ペインを示す Azure portal のスクリーンショット。

証明書を追加する

証明書は、"公開キー" とも呼ばれ、クライアント シークレットより安全であると見なされるため、推奨される資格情報の種類です。 アプリケーションにおける認証方法として証明書を使用する方法について詳しくは、「Microsoft ID プラットフォーム アプリケーションの認証証明書資格情報」を参照してください。

  1. Azure portal の [アプリの登録] で、対象のアプリケーションを選択します。
  2. [証明書およびシークレット]>[証明書]>[証明書のアップロード] の順に選択します。
  3. アップロードするファイルを選択します。 ファイルの種類は .cer.pem.crt のいずれかである必要があります。
  4. [追加] を選択します。

クライアント シークレットの追加

クライアント シークレットは、"アプリケーション パスワード" とも呼ばれ、アプリで自身を識別するために証明書の代わりに使用できる文字列値です。

クライアント シークレットは、証明書の資格情報よりも安全性が低いと見なされます。 アプリケーション開発者は、ローカル アプリの開発時に、その使いやすさからクライアント シークレットを使用することがあります。 ただし、運用環境で実行しているアプリケーションには、証明書の資格情報を使用する必要があります。

  1. Azure portal の [アプリの登録] で、対象のアプリケーションを選択します。
  2. [証明書とシークレット]>[Client secrets]\(クライアント シークレット\)>[新しいクライアント シークレット] の順に選択します。
  3. クライアント シークレットの説明を追加します。
  4. シークレットの有効期限を選択するか、カスタムの有効期間を指定します。
    • クライアント シークレットの有効期間は、2 年間 (24 か月) 以下に制限されています。 24 か月を超えるカスタムの有効期間を指定することはできません。
    • Microsoft では、有効期限の値は 12 か月未満に設定することをお勧めしています。
  5. [追加] を選択します。
  6. クライアント アプリケーションのコードで使用できるように、"シークレットの値を記録します"。 このページからの移動後は、このシークレットの値は "二度と表示されません"。

アプリケーションのセキュリティに関する推奨事項については、「Microsoft ID プラットフォームのベスト プラクティスと推奨事項」を参照してください。

次のステップ