次の方法で共有

application: addKey

  • [アーティクル]

名前空間: microsoft.graph

重要

Microsoft Graph の /beta バージョンの API は変更される可能性があります。 実稼働アプリケーションでこれらの API を使用することは、サポートされていません。 v1.0 で API を使用できるかどうかを確認するには、Version セレクターを使用します。

アプリケーションにキー資格情報を追加 します。 このメソッドは 、removeKey と共にアプリケーションで使用して、期限切れのキーのローリングを自動化できます。

注:

アプリケーションの 作成 操作と アプリケーションの更新 操作を引き続き使用して、ユーザーのコンテキストの有無にかかわらず、任意のアプリケーションのキー資格情報を追加および更新できます。

公開キーの値は、アプリケーションに証明書資格情報を追加する場合にのみ指定する必要があります。 秘密キー証明書をアプリケーションに追加すると、アプリケーションが損なわれます。

このメソッドの要求検証の一環として、アクションを実行する前に、既存のキーの所有証明が検証されます。

既存の有効な証明書がない (証明書がまだ追加されていないか、すべての証明書の有効期限が切れている) アプリケーションでは、このサービス アクションを使用できません。 代わりに、アプリケーションの更新操作を使用して更新を行うことができます。

この API は、次の国内クラウド展開で使用できます。

グローバル サービス 米国政府機関 L4 米国政府機関 L5 (DOD) 21Vianet が運営する中国
✅ ✅ ✅ ✅

アクセス許可

この API の最小特権としてマークされているアクセス許可またはアクセス許可を選択します。 アプリで必要な場合にのみ、より高い特権のアクセス許可またはアクセス許可を使用します。 委任されたアクセス許可とアプリケーションのアクセス許可の詳細については、「 アクセス許可の種類」を参照してください。 これらのアクセス許可の詳細については、 アクセス許可のリファレンスを参照してください。

アクセス許可の種類 最小特権アクセス許可 特権の高いアクセス許可
委任 (職場または学校のアカウント) Application.ReadWrite.All Directory.ReadWrite.All
委任 (個人用 Microsoft アカウント) サポートされていません。 サポートされていません。
アプリケーション Application.ReadWrite.OwnedBy Application.ReadWrite.All, Directory.ReadWrite.All

注:

アプリケーションには、独自のキーをロールするための特定のアクセス許可は必要ありません。

HTTP 要求

アプリケーションのアドレスは、 その ID または appId を使用して行うことができます。 id と appId は、Microsoft Entra 管理センターのアプリ登録でそれぞれオブジェクト ID とアプリケーション (クライアント) ID と呼ばれます。

POST /applications/{id}/addKey
POST /applications(appId='{appId}')/addKey

要求ヘッダー

名前 説明
Authorization ベアラー {token}。 必須です。 認証と承認の詳細については、こちらをご覧ください。
Content-Type application/json. 必須です。

要求本文

要求本文で、次の必須プロパティを指定します。

プロパティ 型 説明
keyCredential keyCredential 追加する新しいアプリケーション キー資格情報。 この使用に必要なプロパティは、型、使用法、キーです。 サポートされているキーの種類は次のとおりです。
  • AsymmetricX509Cert: 使用法は である Verify必要があります。
  • X509CertAndPassword: 使用する必要があります。 Sign
passwordCredential passwordCredential key のパスワードを含める必要がある設定が必要なのは secretText のみです。 このプロパティは、 型 X509CertAndPasswordのキーにのみ必要です。 それ以外の場合は に null 設定します。
証拠 String 既存のキーの所有証明として使用される自己署名 JWT トークン。 この JWT トークンは、アプリケーションの既存の有効な証明書の 1 つの秘密キーを使用して署名される必要があります。 トークンには、次の要求を含める必要があります。
  • aud: 対象ユーザーは である必要があります 00000002-0000-0000-c000-000000000000。
  • iss: 発行者は、要求を開始する アプリケーション の ID である必要があります。
  • nbf: 時間の前ではありません。
  • exp: 有効期限は nbf + 10 分の値にする必要があります。

この所有証明トークンを生成する手順については、「 ローリング キーの所有証明トークンの生成」を参照してください。 要求の種類の詳細については、「 要求ペイロード」を参照してください。

応答

成功した場合、このメソッドは 200 OK 応答コードと、応答本文に新しい keyCredential オブジェクトを返します。

例

例 1: アプリケーションに新しいキー資格情報を追加する

要求

次の例は要求を示しています。

POST https://graph.microsoft.com/beta/applications/{id}/addKey
Content-type: application/json

{
    "keyCredential": {
        "type": "AsymmetricX509Cert",
        "usage": "Verify",
        "key": "MIIDYDCCAki..."
    },
    "passwordCredential": null,
    "proof":"eyJ0eXAiOiJ..."
}

応答

次の例は応答を示しています。

HTTP/1.1 200 OK
Content-Type: application/json

{
    "@odata.context": "https://graph.microsoft.com/beta/$metadata#microsoft.graph.keyCredential"
}

例 2: キーの資格情報と関連付けられたパスワードを追加する

要求

次の例は要求を示しています。

POST https://graph.microsoft.com/beta/applications/{id}/addKey
Content-type: application/json

{
    "keyCredential": {
        "type": "X509CertAndPassword",
        "usage": "Sign",
        "key": "MIIDYDCCAki..."
    },
    "passwordCredential": {
        "secretText": "MKTr0w1..."
    },
    "proof":"eyJ0eXAiOiJ..."
}

応答

次の例は応答を示しています。

HTTP/1.1 200 OK
Content-Type: application/json

{
    "@odata.context": "https://graph.microsoft.com/beta/$metadata#microsoft.graph.keyCredential"
}