第1回「結局はトークンを取得してAPIを叩くだけ」— Microsoft Entra ID（Azure AD）認証の基礎

この記事の内容

Azure の自動化において「認証」とは結局トークンを取得してAPIに渡すことだと理解できます
トークンの実体が JWT（JSON Web Token）であり、デコードすると読める形で情報が含まれていることを確認します
Azure REST API をブラウザから直接呼び出す体験を通じて、認証の仕組みを直感的につかめます
誰がどうやってトークンを取得するかのパターン（ユーザープリンシパル・サービスプリンシパル・マネージド ID）を概観します
Azure PowerShell のセットアップ手順を確認し、以降のハンズオンへの準備を整えます

はじめに：このシリーズの対象と目的

このシリーズは、Azure の処理を自動化したい方を対象にしています。具体的には、次のような課題を持っている方に向けた内容です。

ユーザーによる対話的な認証や多要素認証を省いて、自動化したい
パスワードをスクリプトに直接書くのは避けたい
認証の背後にある仕組みをある程度理解したい
サービスプリンシパルやマネージド ID という言葉は聞いたことがあるが、よくわからない

なお、このシリーズは Azure の操作を PowerShell や Azure CLI で自動化する ことにフォーカスしています。Web アプリや Web API の開発者向けの認証については対象外です。

シリーズは全7回の動画で構成されており、本記事はその第1回にあたります。

認証の本質：「結局はトークンを取得してAPIを叩くだけ」

Azure で何らかの操作をするとき、それが Azure ポータルからの操作であれ、PowerShell による自動化であれ、Azure CLI であれ、最終的にはすべて REST API への呼び出しに行き着きます。

そして、その API を呼び出す際には必ず トークン が必要です。

つまり、認証・自動化を考えるうえで本質的な問いは次の1つです。

「誰が、どうやってトークンを取得するか」

トークンさえ取得できれば、あとはそれを HTTP リクエストのヘッダーに付けて API を呼ぶだけです。これがこのシリーズ全体を貫く基本的な考え方です。

実際に REST API を叩いてトークンを確認する

Azure REST API ドキュメントの「試す」機能を使う

Azure のドキュメントサイト（docs.microsoft.com）には、REST API を直接試せる機能があります。ここでは「リソースグループの作成または更新」API を例に確認します。

API のエンドポイントは次のような構造になっています。

リクエストボディには、リソースを作成するリージョン情報などを JSON で指定します。

{
  "location": "japaneast"
}

ドキュメントページの「試す」ボタンを押すと、Microsoft アカウントや Entra ID アカウントでサインインが求められます。これがまさに「認証」の瞬間です。サインインが完了すると、リクエストが自動的に組み立てられ、実行できるようになります。

Authorization ヘッダーに注目する

リクエストを確認すると、HTTP ヘッダーの中に Authorization という項目があり、そこに非常に長い文字列が含まれていることがわかります。

この長い文字列こそが トークン です。

API の受け側（management.azure.com）は、このトークンを見て「ちゃんと権限を持ったユーザーからのリクエストだ」と判断し、処理を行います。

API 実行結果の確認

「実行」すると HTTP レスポンスコード 200 が返り、リソースグループの作成が成功します。Azure ポータルで該当のサブスクリプション配下のリソースグループを確認すると、指定した名前のリソースグループが実際に作成されています。

トークンの中身：JWT（JSON Web Token）

先ほどの長い文字列は、実は JWT（JSON Web Token） というフォーマットになっています。

JWT は次の3つのパートがドット（.）で連結された構造です。

ヘッダー — トークンの種別や署名アルゴリズム
ペイロード（クレーム） — ユーザー情報や権限などの実データ
署名 — 改ざんされていないことを証明するためのデータ

jwt.io などのサイトに貼り付けてデコードすると、人間が読める形に変換できます。ペイロードには次のような情報が含まれています。

メールアドレス（サインインしたユーザーのアカウント）
どのサービスとして認証されているか
所属しているグループの情報
認証プロバイダー（idp: live.com など）

API の受け側はこのトークンを受け取り、署名が正当であること（改ざんされていないこと）を確認したうえで、ペイロードの情報をもとに「誰が、どの権限でリクエストしてきたか」を判断します。

トークンはどこから取得するのか

トークンの発行元は Microsoft ID プラットフォーム（Entra ID） です。エンドポイントの構造は次のようになっています。

OAuth 2.0 や OpenID Connect といったプロトコルに基づいており、様々なフロー（認可コードフロー、クライアントクレデンシャルフローなど）でトークンを取得できます。フローの詳細はドキュメントの「シナリオとサポートされている認証フロー」に記載されています。

ただし、どのフローを使ったとしても、最終的には「トークンを付けて API を呼ぶ」という部分は共通です。

誰がどうやってトークンを取得するか：3つのパターン

Azure の自動化に関係する主なパターンは次の3つです。

1. ユーザープリンシパル（対話操作）

最も一般的なパターンです。ユーザーが ID とパスワードを入力し、多要素認証を経て認証します。Outlook でメールを確認するときや、Azure ポータルにログインするときがこれにあたります。

特徴： 人間が操作するため、完全な自動化には不向きです。

2. サービスプリンシパル（資格情報による認証）

人間ではなく、アプリケーションやサービスが主体となって認証するパターンです。パスワード（クライアントシークレット）や証明書を使って認証します。

特徴： 自動化スクリプトやバッチ処理での利用に適しています。資格情報の安全な管理（Key Vault の活用など）が重要になります。

3. マネージド ID

Azure 上のサービス（仮想マシン、Azure Functions など）自体が ID を持つ仕組みです。資格情報を自分で管理する必要がなく、Azure が自動的に管理します。

特徴： 最もセキュアな方法の一つです。Azure リソース上で動作する処理に適しています。

このシリーズでは、これら3つのパターンをすべてハンズオンで確認していきます。

ハンズオン環境の準備

ハンズオンを進めるために、次の環境が必要です。

Entra ID（Azure AD）の管理者権限 — アプリケーション登録を行うため
Azure サブスクリプション（所有者権限） — リソースの作成と権限付与のため
Windows 端末 — 証明書を使うハンズオンで Windows を前提とした手順があるため

Azure の評価版（無料試用版）をお持ちでない方は、クレジットカードを1枚用意することで作成できます。評価版では今回のハンズオンに必要な権限がすべて含まれています。

Azure PowerShell のインストール

ハンズオンでは主に Azure PowerShell を使用します。次のコマンドでインストールできます。

Install-Module -Name Az -Scope CurrentUser

すでに古い AzureRM モジュールがインストールされている場合は、先に Az モジュールをインストールしてから AzureRM を削除する必要があります。

# Az モジュールをインストール
Install-Module -Name Az -Scope CurrentUser

# AzureRM モジュールを削除（Windows PowerShell を管理者として実行）
Uninstall-AzureRm

AzureRM の削除は Windows PowerShell を管理者として実行した状態で行う必要があります。

まとめ

この記事では、Azure 認証の本質を「トークンを取得して API に渡すだけ」というシンプルな考え方で整理しました。

Azure のあらゆる操作は最終的に REST API への呼び出しになります
API を呼び出す際は Authorization ヘッダーにトークン（JWT）を付与します
トークンにはユーザー情報や権限情報が含まれており、API の受け側はこれをもとに処理の可否を判断します
トークンの発行元は Microsoft ID プラットフォーム（Entra ID）です
自動化において重要なのは「誰が・どうやってトークンを取得するか」であり、ユーザープリンシパル・サービスプリンシパル・マネージド ID という3つのパターンがあります

次回は、ユーザープリンシパルが対話操作でトークンを取得するパターンをハンズオンで確認していきます。