あなたはEntra IDを理解できる

はじめに

ヘッドウォータースに入社し、初めてクラウドという概念に本格的に触れました。
業務のなかでAzureのキャッチアップを進めていましたが、理解が難しい概念がありました。

それがEntra IDです。

今回は自分なりに理解したその概念を、具体的な使い方のイメージを多めにして入門者の方でも理解しやすい記事にしてみました。

認証の「抽象化」とクラウドの全体像

クラウドやAzureを学ぶ際、最大の壁となるのが「Microsoft Entra ID（旧Azure AD）」です。
「クラウドベースのID管理サービス」という言葉だけでは、実態は掴めません。

Entra IDの本質は、「私たちが普段Webアプリで作っているログイン機能を、極限まで高度に切り出し、外部API化したもの」です。この記事では、開発者の視点からEntra IDがシステム的に何をしているのかを紐解きます。

👦利用者から見たEntra ID

システムの内部構造を見る前に、まずは「企業（利用者）」の視点から、Entra IDがどう使われているのか全体像を把握しましょう。

大前提として、Entra IDは個人向けのWebサービスのように「ユーザー自身が勝手にアカウントを作れるもの」ではありません。企業が自社のセキュリティを守るために導入する、組織専用の管理システムです。

1. テナントとユーザーの登録

企業がEntra IDの利用を開始すると、クラウド上に自社専用の空間（テナント）が作成され、組織固有の「テナントID」が割り当てられます。
そして、会社のシステム管理者が、そのテナント内に従業員のアカウントを作成し、個別のユーザーID（オブジェクトID）を発行します。「管理者が事前に登録・許可した人」でなければ、連携するシステムを利用することは一切できません。

2. 社内システムと「社外のSaaS」を繋ぐ

企業から見たEntra IDの最大の役割は、自社開発のシステムだけでなく、Salesforce、Zoom、Google Workspaceといった「社外のクラウドサービス（SaaS）」に対する共通のログイン基盤になることです。

世の中の主要なクラウドサービスの多くは、初めからEntra IDと連携してログインする仕組みに対応しています。

3. なぜこの仕組みが必要なのか？（シングルサインオンの力）

もしEntra IDがなければ、従業員は利用する社外サービスの数だけ、別々のパスワードを管理しなければなりません。これは利用者の負担になるだけでなく、簡単なパスワードの使い回しや、退職時の「アカウント消し忘れ」による情報漏洩リスクに直結します。

すべてのサービスのログインをEntra IDに連携（委譲）することで、以下のような劇的なメリットが生まれます。

• 従業員（利用者）：朝、PCを開いてEntra IDに1回ログインするだけで、連携しているすべての社内外のシステムにパスワード入力なしでそのままアクセスできます（シングルサインオン：SSO）。
• システム管理者：従業員が退職した際、Entra ID上のアカウントを1つ「無効化」するだけで、連携している数十個の社外サービスすべてから即座にアクセスを遮断できます。

このように、Entra IDは「許可された従業員だけが、社内外のあらゆるサービスへ安全にアクセスするための、中央集権的な入場ゲート」として機能しています。

では、この「外部のサービスへログインを任せる」という仕組みは、システム内部（プログラムやインフラ）でどのように実装されているのでしょうか？次の章から、開発者の視点でその構造を紐解いていきます。

💡 コラム：実はあなたの会社も、すでにEntra IDを使っている？

ここまで読んで、「じゃあ、うちの会社はどこからEntra IDに登録すればいいの？」と疑問に思った方もいるかもしれません。

実は、ほとんどの企業は「Entra IDというサービス単体」でわざわざ新規契約をしているわけではありません。企業が自社専用のEntra ID環境（テナント）を手に入れる、最も一般的な入り口は「Microsoft 365（旧Office 365）」です。

企業が「全社でTeamsを使おう」「会社のメールアドレス（Outlook）を作ろう」とMicrosoft 365の法人プランを契約した瞬間、裏側では自動的に、その企業専用のEntra IDが構築されています。 同様に、自社のインフラとして「Azure」の利用を開始した際にも、初期状態でEntra IDが立ち上がります。

つまり、Entra IDは単なる後付けのセキュリティツールではなく、Microsoftの法人向けクラウドを動かすための「共通の土台」なのです。「知らず知らずのうちに、すでに自社でEntra IDが動いていた」というケースがほとんどなのは、このためです。

そして最大のポイントは、この「M365の裏で動いているEntra ID」を使って、SalesforceやAWSといった全く別の社外サービスと連携（SSO）させることも可能だということです。
普段TeamsやOutlookにログインしているのと同じIDとパスワードが、会社が許可したすべてのサービスを開く「マスターキー」になるのです。

👨‍💻システム開発者から見たEntra ID

では、システム開発者の視点から、Entra IDがどのように機能しているのかを見ていきましょう。

Entra IDは、「認証の抽象化レイヤー」として機能します。つまり、私たちが普段Webアプリで作っているログイン機能を、極限まで高度に切り出し、外部API化したものです。

1. 従来の「自前ログイン」からの脱却

従来のWebアプリでは、自前でデータベースに Users テーブルを作り、パスワードのハッシュ化や照合プログラムを書いていました。

Entra IDを導入するということは、この「ユーザー管理」と「ログイン検証」を自分のシステムから完全に切り離し（抽象化し）、外部システムに委譲することを意味します。

以下の図は、Entra IDを利用したログイン処理の流れです。

このように、Entra IDは「超高機能なログイン専用の外部API」として機能します。

以上の図はあくまで簡易的なイメージです。
実際には、ログイン後に返るのは「認可コード」です。
アプリはそのコードをEntra IDに渡して、はじめて「トークン」を受け取ります。

実際の実装では、MSALを使ってこのコードのやり取りを自動化することが多いです。
その場合、コード上ではMSALにクライアントIDやスコープを指定して「トークンを取ってきて」とお願いするだけで、裏側でこの一連の流れが処理されます。

2. トークンの正体と「偽造防止」の仕組み

Entra IDが発行する証明データ（トークン）の多くは、JWT（JSON Web Token）という規格で作られています。

アプリはトークンを受け取った際、「このトークンは偽造されていないか？」を厳密にチェックします。チェックする主なポイントは以下の3点です。

1. デジタル署名の検証:
   • トークンには、Entra IDだけが持つ「秘密鍵」で暗号的なハンコ（署名）が押されています。
   • アプリは、Entra IDが公開している「公開鍵」を使って、このハンコが本物であり、中身が改ざんされていないかを数学的に検証します。
2. 有効期限の確認:
   • トークン内の「有効期限（例：発行から1時間）」が切れていないかを確認します。
3. 宛先（Audience）の確認:
   • 「このトークンは、間違いなく自分のアプリ宛てに発行されたものか」を確認し、他アプリからの流用を防ぎます。

3. トークンの種類

Entra IDが発行するトークンは、ユーザの認証だけが目的ではありません。
アプリがシステムバックエンドのAPIや、Microsoft Graph APIなどのMicrosoftのサービスを呼び出す際にも、トークンが必要になります。

そもそも、Entra IDが発行するトークンには、主に「IDトークン」と「アクセストークン」の2種類があります。

トークンの種類	役割	使われる場面
IDトークン	認証の証明。ユーザーのIDや属性情報が含まれる。	クライアント側でのユーザー認証
アクセストークン	認可の証明。属性情報と権限情報が含まれる。	API呼び出し時の権限確認

IDトークン

IDトークンは、ユーザーが誰であるかを証明するためのトークンです。ユーザーの名前やメールアドレスなどの属性情報が含まれています。アプリはこのトークンを検証することで、「このユーザーは誰か？」を知ることができます。

主にはクライアント側でのユーザー認証に使われます。

アクセストークン

アクセストークンは、ユーザーがどのような権限を持っているかを証明するためのトークンです。
ユーザーの属性情報に加えて、どのリソースに対してどのような操作が許可されているかの情報が含まれています。
APIはこのトークンを検証することで、「このユーザーはこの操作をしてもよいか？」を判断します。

主にはAPI呼び出し時の権限確認に使われます。

取得したトークンでMicrosoftのサービスを呼び出す

アクセストークンはシステムのAPIを呼び出すためだけのものではありません。
Microsoft Graph APIなどのMicrosoftのサービスを呼び出す場合にも、同じように利用します。

例えば、Microsoftが提供する統合APIであるMicrosoft Graph API（https://graph.microsoft.com）に、トークンを Authorization: Bearer <トークン> ヘッダーで渡すだけで、Microsoft 365の各サービス（メール、カレンダー、OneDriveなど）を操作できます。

例：ログイン中のユーザー情報を取得する

例えば、Microsoft Graph APIを呼び出して、ログイン中のユーザーのプロフィール情報を取得する場合は、以下のようなコードになります。

import requests

access_token = "eyJ0eXAiOiJKV1Qi..."  # Entra IDから取得したトークン

response = requests.get(
    "https://graph.microsoft.com/v1.0/me",
    headers={"Authorization": f"Bearer {access_token}"}
)

user = response.json()
print(user["displayName"])  # 例: "山田 太郎"
print(user["mail"])         # 例: "[e-mail]"

このように、「トークンを Authorization: Bearer ヘッダーに乗せてAPIを呼び出す」という一連の流れが、Entra IDを使ったMicrosoftサービス連携の基本パターンです。

4. アプリの登録と「スコープ（権限）」

Entraアプリ
Entra IDは、誰からの要求でも無条件にトークンを発行するわけではありません。事前に「アプリの登録（Entraアプリ）」が必要です。
アプリを登録すると専用のIDが発行されます。認証を要求する際、「私は〇〇というアプリです」と名乗るために使います。このIDを「クライアントID」あるいは「アプリID」と呼びます。

スコープ
さらに、アプリがトークンを発行してもらうためには、「このアプリはどのリソースに対して、どんな操作をしたいのか？」をEntra IDに事前に登録しておく必要があります。
その内容をユーザーに提示して同意を得ることで、初めてトークンに「このアプリは、あなたのカレンダーを読み取ることができます」といった権限が書き込まれます。
この仕組みを「スコープ」と呼びます。

例えば、あなたが社内カレンダーアプリにログインしたとして、そのアプリがあなたのメール全文を読んだり、あなたになりすまして別のユーザーを削除したりできたとしたら、怖いですよね？

例：カレンダーアプリの場合

あるサードパーティ製のカレンダーアプリが「Microsoft 365のスケジュールを読み取りたい」という場合を考えます。

1. アプリの登録: そのカレンダーアプリの開発者は、事前にEntra ID上にアプリを登録し、専用の「クライアントID」を取得します。このIDが「私は〇〇というアプリです」と名乗るための証明になります。

2. スコープの要求と同意画面: ユーザーがそのアプリでログインしようとすると、Entra IDは以下のような「同意画面（コンセント画面）」を表示します。

   「カレンダーアプリが以下の権限を要求しています：

   • あなたのカレンダーの読み取り（Calendars.Read）

   許可しますか？」

   ここでユーザーが「許可」をクリックしてはじめて、アプリはその権限を含んだトークンを受け取れます。

3. トークンへの書き込み: 発行されたトークンには、許可されたスコープ（Calendars.Read）が記録されています。Microsoft 365のAPIは、そのトークンに記載されたスコープを確認し、「カレンダーの読み取りだけ」に応答します。メールの読み取りや、ユーザー削除といった操作は、スコープに含まれていないため拒否されます。

このように、スコープは「ログインしたことの証明（認証トークン）」に「何をしてよいかの範囲（認可）」を上乗せするための仕組みです。

スコープの主な例

スコープ名	許可される操作
User.Read	自分のプロフィール情報を読み取る
Calendars.Read	カレンダーの予定を読み取る
Mail.Send	メールを送信する
Files.ReadWrite	OneDrive上のファイルを読み書きする

• 権限の最小化: トークンには許可されたスコープだけが書き込まれます。万が一トークンが漏洩しても、そのスコープの範囲外の操作は一切できないため、被害を最小限に抑えられます。

5. Azureリソース間通信でも同じ仕組みが使われる

ここまではユーザー（人間）がログインしてトークンを取得する流れを説明してきました。実はAzureのリソース同士が通信する場合も、まったく同じ仕組みが使われています。

かつては、WebアプリからAzure Storageに接続するためにアクセスキー（パスワード）をコードに直書きするのが一般的でした。しかしこれは、コードが流出した瞬間にStorageへの無制限アクセスを許してしまうリスクがありました。

現在は、Webアプリ自身がEntra ID上のオブジェクトIDを持ち、そのオブジェクトIDでEntra IDからトークンを取得してStorageにアクセスします。アクセスキーはどこにも存在しません。

この仕組みを「マネージドID（Managed Identities）」と呼びます。
詳しくは別の記事で解説予定です。

まとめ

Entra IDの全体像は、以下の4点に集約されます。

• 認証の外部化：パスワード管理や照合処理を切り離し、セキュアな外部サービスに任せる仕組み。
• 偽造防止の仕組み：公開鍵暗号を用いたデジタル署名により、トークンの正当性をアプリ側で検証する。
• アプリ登録とスコープ：どのアプリが、どの範囲の権限を求めているかを厳密に管理する。
• トークンによるAPIの呼び出し：取得したトークンを Authorization: Bearer ヘッダーに付与することで、Microsoft Graph APIなどのサービスを呼び出せる。
• システム間連携の要：Azure内部でもアクセスキーの直書きを避け、Entra IDが発行するトークンを使ってリソース同士が安全に通信している。

「プログラムの処理を外部システムに委譲している」という構造のイメージを持てば、複雑なクラウドセキュリティの概念も、論理的なパズルとして綺麗に繋がるはずです。