この記事の内容

  • アクセストークンには「誰が」「どうやって」に加え、どのサービス宛てか（Audience） という情報が含まれる
  • Azure Resource Manager 用と Microsoft Graph 用ではトークンの Audience が異なる
  • PowerShell でトークンを取得する際は -ResourceUrl オプションで対象サービスを明示する必要がある
  • Microsoft Graph や Azure Portal などは Entra ID にサービスプリンシパルとして登録されている
  • シリーズ全体の振り返りとして、Azure 自動化における安全な認証フローを整理する

はじめに

本記事は「Microsoft Entra ID の認証の話（Azure 周りの自動化編）」シリーズの最終回、第7回の内容をまとめたものです。

このシリーズは、Azure の処理を自動化したい方に向けて、ユーザーによる対話的な認証を省いた安全な自動化を実現するための認証周りの知識を解説してきました。本記事では、これまで意図的に触れてこなかった重要なポイント——トークン取得時に対象サービスを明示すること——について詳しく説明します。

トークンには「宛先」がある

これまでのシリーズでは「誰が（Who）」「どうやって（How）」トークンを取得するかを中心に解説してきました。しかし実は、トークン取得においてもう一つ超重要な要素があります。それが 「どこにアクセスするためのトークンなのか」 です。

アクセストークンをデコードすると、aud（Audience）というクレームが含まれています。このシリーズで扱ってきた Azure の操作では、Audience は常に以下のようになっています。

management.core.windows.net

これは Azure Resource Manager（ARM）向けのトークンであることを示しています。

Microsoft Graph のトークンは別物

試しに Microsoft Graph Explorer でトークンを取得し、同様にデコードしてみると、Audience が全く異なる値になっていることがわかります。

Azure 向けのトークンと Microsoft Graph 向けのトークンは、別のサービスに対して発行されたトークンであるため、Audience が異なります。間違ったサービスのトークンを使ってリクエストを送ると、次のようなエラーが返ってきます。

4AA0uc1tcheUesnnsatuittcohakoterinioznve_adTloikdeantEixopnirfeadiled.Audiencedoesn'tmatch.

これは「お前に宛てたトークンじゃないぞ」というエラーです。

サービスプリンシパルとして存在する Microsoft のアプリケーション

Microsoft Graph は Entra ID にサービスプリンシパルとして登録されています。Entra ID のエンタープライズアプリケーションで Microsoft Graph の Application ID を検索すると、実際にサービスプリンシパルが存在することを確認できます。

同様に、Azure Portal 自体も Entra ID にアプリケーションとして登録されています。Azure Portal にサインインするということは、Azure Portal というアプリケーションに対して認証しているということであり、そのサービスプリンシパルが存在するから認証が成立しています。

Microsoft が事前に登録しているこれらのファーストパーティーアプリケーションは、知らないうちにテナントのエンタープライズアプリケーション一覧に存在しています。これは仕様であり、Microsoft が Azure や M365 のサービスを提供するために必要なものです。

PowerShell で Microsoft Graph を叩く方法

PowerShell で Get-AzAccessToken を使う場合、何も指定しないと Azure Resource Manager 用のトークンが取得されます。Microsoft Graph を叩くためのトークンを取得したい場合は、-ResourceUrl オプションで対象を明示する必要があります。

# まず Azure にサインイン
Connect-AzAccount

# Azure Resource Manager 用トークン（デフォルト）
Get-AzAccessToken

# Microsoft Graph 用トークンを明示的に取得
Get-AzAccessToken -ResourceUrl "https://graph.microsoft.com"

このようにして取得したトークンを Authorization ヘッダーに設定することで、Microsoft Graph API を PowerShell から直接呼び出すことができます。

$token = (Get-AzAccessToken -ResourceUrl "https://graph.microsoft.com").Token

$headers = @{
    Authorization = "Bearer $token"
}

Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/users" -Headers $headers

Audience の検証はセキュリティ上必須

なぜ Audience の一致チェックが必要なのかというと、セキュリティ上の理由があります。

もし Audience の検証がなければ、悪意のある API が受け取ったトークンをそのまま別のサービスに横流しするという攻撃が成立してしまいます。Audience を検証することで、発行されたトークンが想定されたサービス以外では使えないようになっており、これがトークンの安全性を担保する重要な仕組みになっています。

シリーズ全体の振り返り

7回にわたるシリーズで学んだことを整理します。

トークン取得の基本

Azure を自動化する際の認証において最も重要なのは、安全にトークンを取得することです。トークンがあれば、そのトークンを API に渡すことで操作が実現できます。

自動化における推奨パターン

シナリオ推奨方法
Azure リソース上で動くワークロードManaged ID を使用
Entra ID をまたぐシナリオKey Vault に証明書を格納 + Managed ID でアクセス
自動化全般サービスプリンシパルを使用

具体的には次のフローが推奨です。

  1. 第一歩: Managed ID を使えるなら積極的に使う。パスワードや証明書の管理が不要で最もシンプル
  2. 第二歩以降: Key Vault に証明書やシークレットを安全に格納し、Managed ID を使って Key Vault にアクセスする
  3. Key Vault から取り出した情報を使って、サービスプリンシパルとしてトークンを取得し、目的の API を呼び出す

対象サービスの明示

Azure Resource Manager 以外のサービス（Microsoft Graph など）を叩きたい場合は、必ず対象サービスを明示してトークンを取得してください。

# Azure リソースマネージャー以外のサービスを叩く場合
Get-AzAccessToken -ResourceUrl "https://対象サービスのURL"

まとめ

本記事では、アクセストークンに含まれる Audience（宛先） の概念と、トークン取得時に対象サービスを明示することの重要性について解説しました。

Azure Resource Manager の世界だけで操作している場合は Audience を省略してもうまく動きますが、Microsoft Graph や他のサービスを叩く場合は明示的に指定が必要です。この点を理解しておくことで、Azure の自動化にとどまらず、Microsoft Graph など他の領域でもこのシリーズで学んだ知識を活用できるようになります。

Azure 自動化の認証を安全に実装するための要点は次のとおりです。

  • Managed ID を第一候補として使用する
  • Key Vault に証明書やシークレットを格納し、Managed ID でアクセスする
  • サービスプリンシパル で自動化フローを構築する
  • Azure Resource Manager 以外のサービスを利用する際は -ResourceUrl で対象を明示してトークンを取得する