Azure AD認証でAzure REST APIを叩く！

この記事の内容

  • Azure REST APIをPostmanから直接呼び出す方法を解説します
  • Azure ADにアプリケーションを登録し、クライアントIDとシークレットを取得する手順を説明します
  • 取得したアクセストークンを使ってREST APIで認証を通す仕組みを理解します
  • リソースグループの一覧取得・作成・削除をREST APIで実行する具体的な手順を紹介します
  • 「認証（Authentication）」と「認可（Authorization）」の違いについても整理します

はじめに

Azure PortalからリソースグループのCRUD操作を行うことは非常に簡単です。しかし、何かを自動化したい、プログラムから操作したいというケースでは、Azure REST APIを直接呼び出す必要が出てきます。

また、Azure CLIにはまだコマンドが存在せず、REST APIしか提供されていない機能もあります。そうした場面に備えて、REST APIの使い方を一度押さえておくことは非常に重要です。

なお、Portalで行っている操作も、裏側ではREST APIを叩いています。本記事では、その仕組みをPostmanを使って手を動かしながら理解していきます。

全体の流れ

今回実施する内容は以下の3ステップです。

  1. Azure ADにアプリケーションを登録し、権限を付与する
  2. アクセストークンを取得する
  3. トークンを使ってREST APIを呼び出す（一覧・作成・削除）

認証なしで叩くとどうなるか

まず、認証なしで試してみます。Azure REST APIのリファレンスから、リソースグループ一覧を取得するエンドポイントをコピーしてPostmanに貼り付け、GETリクエストを送信します。

GEThttps://management.azure.com/subscriptions/{subscriptionId}/resourcegroups?api-version=2021-04-01

{subscriptionId} の部分を自分のサブスクリプションIDに置き換えてSendすると、以下のようなエラーが返ってきます。

{
  "error": {
    "code": "AuthenticationFailed",
    "message": "Authentication failed. The 'Authorization' header is missing."
  }
}

Authorizationヘッダーがないと怒られます。これは当然の結果です。認証情報を渡していないので、APIは誰がリクエストしているのか判断できません。

Azure ADへのアプリケーション登録

アプリケーションの作成

Azure Portalから「Azure Active Directory」→「アプリの登録」→「新規登録」を選択します。

  • 名前: 任意（例: test-app）
  • サポートされているアカウントの種類: 既定のままで問題ありません

登録すると「アプリケーション（クライアント）ID」が発行されます。このIDは後で使用しますので控えておきます。

クライアントシークレットの作成

「証明書とシークレット」→「新しいクライアントシークレット」を選択してシークレットを生成します。

注意: 証明書を使う方がセキュアですが、今回はテスト・学習目的のためクライアントシークレットを使用します。生成直後に表示される「値」をコピーしておいてください。一度画面を離れると二度と確認できません。

テナントIDの確認

「Azure Active Directory」の概要画面から「テナントID」（ディレクトリID）を確認しておきます。

サービスプリンシパルへの権限付与

作成したアプリケーションは、それ自体ではまだ何もできません。操作対象のサブスクリプションに対してロールを割り当てる必要があります。

アプリケーションは「サービスプリンシパル」とも呼ばれます。ユーザーに権限を付与するのと同様に、サービスプリンシパルにもRBACでロールを割り当てます。

  1. Azureポータルで対象の「サブスクリプション」を開く
  2. 「アクセス制御（IAM）」→「ロールの割り当ての追加」
  3. ロール: 「共同作成者」を選択
  4. メンバーの選択で「サービスプリンシパル」を選び、先ほど作成したアプリを検索して選択
  5. 「レビューと割り当て」で確定

これでサービスプリンシパルがサブスクリプション全体に対して共同作成者の権限を持ちました。

アクセストークンの取得

アクセストークンは以下のエンドポイントに対してPOSTリクエストを送ることで取得できます。

POSThttps://login.microsoftonline.com/{tenantId}/oauth2/token

{tenantId} はAzure ADのプライマリドメイン（例: contoso.onmicrosoft.com）またはテナントIDを指定します。

ヘッダー

キー値
Content-Typeapplication/x-www-form-urlencoded

ボディ（x-www-form-urlencoded形式）

キー値
grant_typeclient_credentials
client_id（先ほど作成したアプリケーションのクライアントID）
client_secret（生成したクライアントシークレット）
resourcehttps://management.azure.com/

resource には「これからアクセスしたいAPI（Azure管理API）のURL」を指定します。

レスポンス

リクエストが成功すると、以下のようなレスポンスが返ってきます。

{
  "token_type": "Bearer",
  "resource": "https://management.azure.com/",
  "access_token": "eyJ0eXAiOiJKV1QiLCJ..."
}

access_token の値を控えておきます。このトークンには有効期限があり、期限が切れたら再度取得する必要があります。

REST APIでリソースグループを操作する

取得したアクセストークンをAuthorizationヘッダーにセットして、各操作を実行します。

ヘッダーの設定（共通）

キー値
AuthorizationBearer {取得したaccess_token}

リソースグループ一覧の取得

GEThttps://management.azure.com/subscriptions/{subscriptionId}/resourcegroups?api-version=2021-04-01

成功すると、サブスクリプション内のリソースグループ一覧がJSON形式で返ってきます。

{
  "value": [
    {
      "id": "/subscriptions/.../resourceGroups/my-rg",
      "name": "my-rg",
      "location": "japaneast",
      "type": "Microsoft.Resources/resourceGroups",
      "properties": {
        "provisioningState": "Succeeded"
      }
    }
  ]
}

Portalの画面で見えているものと同じ内容が返ってくることが確認できます。

リソースグループの作成

PUThttps://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}?api-version=2021-04-01

追加ヘッダー

キー値
Content-Typeapplication/json

リクエストボディ

{
  "location": "japaneast"
}

location は必須項目です。成功すると作成されたリソースグループの情報が返ってきます。

リソースグループの削除

DELETEhttps://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}?api-version=2021-04-01

ボディは不要です。Authorizationヘッダーにトークンをセットして送信します。成功すると 202 Accepted が返り、リソースグループが削除されます。

認証（Authentication）と認可（Authorization）の違い

今回の操作を通じて、2つのステップが明確に分離されていることがわかります。

内容
認証（Authentication）「あなたは誰か」を確認するステップ。クライアントIDとシークレットを使ってAzure ADにトークンを要求する部分がここにあたります。
認可（Authorization）「その操作をしてよいか」を確認するステップ。トークンをREST APIに渡したとき、そのサービスプリンシパルが該当のリソースに対する権限を持っているかがチェックされます。権限がなければ403エラーが返ります。

この2つは完全に分離されています。認証が通ってもサービスプリンシパルに権限が付与されていなければ操作はできません。

まとめ

今回はPostmanを使って、Azure AD認証によりAzure REST APIを直接呼び出す手順を確認しました。

  1. Azure ADにアプリケーションを登録し、クライアントIDとシークレットを発行する
  2. サービスプリンシパルにRBACでロールを割り当て、操作対象リソースへのアクセス権を付与する
  3. /oauth2/token エンドポイントにPOSTして、Bearerトークンを取得する
  4. 取得したトークンを Authorization: Bearer {token} ヘッダーにセットして各REST APIを呼び出す

認証部分のセットアップさえ理解してしまえば、後はAzure REST APIリファレンスを見ながら様々なリソースを操作できるようになります。Azure CLI にまだ存在しない機能や、プログラムからの自動化を検討している方は、ぜひ一度自分の手でREST APIを叩いてみてください。