概要
最近Azureでアプリの登録を使って Entra ID 認証を構築する機会が多かったので、アプリの登録について自分の中での理解をまとめておこうと思います。正直使っていても全く理解しきれている気がしません。
1. アプリの登録とは
「アプリの登録」という名前から、最初「WebアプリをAzureに登録する」「URLを設定するとそのアプリが登録される」ということを想像していました。が、そういうわけではありません。
Azure のアプリの登録とは、実際には 「Entra ID にアプリケーションという論理的な存在を定義する」 ことです。実体の Webアプリ や API そのものではなく、認証・認可のための識別子とルールの集合です。そのため「アプリの設計図」と表現されているのを見かけます。
実際に登録されるもの
- アプリケーション ID（Client ID）
- トークンを発行してよい対象(リダイレクトURI)
- どの認証フローを使うか
- どの権限を要求できるか
Client ID (誰に)
Azure Entra ID は、アプリの登録の Client ID を使うことで、「この要求は誰から来たのか」を識別し、「どんな認証フロー」で「どの権限を」「どこに渡してよいか」を判断することが出来ます。
リダイレクトURI（どこに）
リダイレクトURI は、認証が完了したあとにトークンを返してよい送信先をAzureが制限するための仕組みで、それ以外には絶対に返さないようにしています。Azure は Client ID とリダイレクトURI の組み合わせを見て、トークンを返してよいかどうかを判断します。URI は 完全一致でワイルドカードは不可、またローカル開発環境（http://localhost/<endpoint>）以外のhttp通信は設定できず、必ずhttpsのURIが必要です。
認証フロー（どうやって）
アプリの登録では「どんな方法で認証を行えるか」を設定できます。Azure が実際に判断しているのは、
- ブラウザを使う対話型ログインか
- ユーザーなしで動くか
- 秘密情報（secret / 証明書）を持てるか
ですが、これらはアプリの性質によって使えるものが決まっています。
| 認証フロー | 主な用途 | ブラウザ対話ログイン | ユーザーなし動作 | secret / 証明書 | 代表例 |
|---|---|---|---|---|---|
| Authorization Code | ユーザーがログイン | ○ | ✕ | ○ | BFF / Web App |
| Authorization Code + PKCE | SPA | ○ | ✕ | ✕ | React / Vue |
| Client Credentials | アプリのみ | ✕ | ○ | ○ | バッチ / サービス |
| On-Behalf-Of(OBO) | API が代理実行 | ✕ | ✕ | ○ | API → 別API |
（どの）権限
アプリの登録では「このアプリは何をしてよいか」の権限設定ができます。権限はAPIごとに定義されており、細かく制御する必要があります。権限取得が可能なAPIの例として
- Microsoft Graph
- Power Platform API
- 自作 API（Expose an API）
などがあげられます。権限には Delegated, Application の2つの権限があります。Azure Portalの日本語では「委任されたアクセス許可」「アプリケーションの許可」と表示されています。
| 種類 | 実行主体 | 典型用途 | かみ砕くと |
|---|---|---|---|
| Delegated 権限 | ユーザー | Webアプリ | 「ユーザーの身分を借りて実行する」権限 |
| Application 権限 | アプリ | バッチ処理 | 「アプリが自分の身分で実行する」権限 |
2. アプリ登録を使うユースケース
概念的なことだけ読んでも何のことやらイメージが付きにくいので実際のユースケースに沿って、アプリの登録が実際に何をするのかを解説します。
a. ユーザーがログインする Webアプリ
シナリオ
社内向けの Webアプリがあり、Azure Entra ID のユーザーにログインしてもらいたい。
ということを考えます。
ここで Azure が判断すべきことは、
- このログイン要求は どのアプリから 来たのか
- ユーザーは どこまでの操作を許可 するのか
- ログイン後、どこに 戻してよいのか
になります。そこでアプリの登録では以下を管理します。
| 管理項目 | 管理している意味 |
|---|---|
| 認証フロー | SPA か Web App かで安全な方法が違う |
| 要求できる権限 | 権限の限定 |
| リダイレクト URI | トークンを返してよい場所を限定 |
| トークン発行対象 | 対象の Client ID 宛なら OK を判断 |
b. Webアプリ が バックエンドAPI を呼ぶ
シナリオ
フロントエンドはユーザーが操作し、実際の処理は バックエンドAPI が行う構成。
ということを考えます。
ここで Azure が判断すべきことは、
- この API は 誰のための API なのか
- どのアプリからの呼び出しを 信頼してよいのか
- ユーザーの権限を どこまで引き継ぐのか
になります。そこでアプリの登録では以下を管理します。
| 管理項目 | 管理している意味 |
|---|---|
| API 用アプリ登録 | API 自体の「身分証」 |
| スコープ定義 | 何ができる API か |
| トークンの audience | この API 宛かを検証 |
| 呼び出し元の制限 | 想定外のアプリを排除 |
c. 人がいないバッチ・自動処理
シナリオ
定期的に Microsoft Graph や社内 API を呼ぶバッチ処理やバックグラウンドジョブがある。
ということを考えます。この場合は
- ユーザーが存在しない
- ログイン画面も出せない
という条件のため、ユーザー前提の認証フローが使えません。そこで、アプリの登録では以下を管理します。
| 管理項目 | 管理している意味 |
|---|---|
| アプリケーション権限 | ユーザー不在でも動かす |
| 証明書 / シークレット | なりすまし防止 |
| スコープ定義 | 何ができる 処理かを管理 |
まとめ
実際のアプリではa,bを両方使うOBOフローの実装、bのバックエンド認証のみでフロントエンドの処理にも対応するBFF（Backend for Frontend）実装など様々なケースがあります。「このアプリは、どんな立場で、何をしてよいのか」をアプリ作成者がちゃんと認識して構築することが重要です。（とそれっぽく言いつつ実際どういうときにどう実装すればいい？と聞かれると自分はパッとは答えられません……）
3. アプリの登録はどういう基準で分割すべきか
アプリの登録は、同じ信頼レベル・同じ責任範囲で振る舞う主体ごとに分けます。同じ Client ID に様々な権限や認証フローを追加していくと当然トークンなどが漏洩した時のリスクも増えます。そのため、責任範囲の違う主体の使う Client ID は別々に分割するべきであるということです。
アプリの登録を分けるべき判断基準
要求・付与される権限が違う(最小権限原則)
- Delegated（委任されたアクセス許可） と Application（アプリケーションの許可） が混ざる → 実行主体が違う
- 強い権限（管理・書き込み）が一部だけ必要
認証フローが違う
- SPA（PKCE）
- Web / BFF（Authorization Code）
- バッチ（Client Credentials）
秘密情報の扱いが違う
- secret を持てる
- 持てない
- マネージドID を使う
管理・運用の責任者が違う
- 別チーム
- 別ベンダー
- 本番と開発で分離
分けない
認証は機能の境界ではないので、当然ですが以下のような極端な分け方はしません
- 画面ごと
- 機能ごと
- エンドポイントごと
参考 Microsoft Learn
アプリケーションを Microsoft Entra ID に登録する
Microsoft Entra ID でのアプリケーション プロパティのセキュリティに関するベスト プラクティス
リダイレクト URI (応答 URL) の概要と制限
Microsoft Entra ID でアプリの要求されたアクセス許可を更新する
理解を深めたいキーワード
個人的にふわっとした理解しかできていなくてとりあえず実装になっていたり、なんとなくで設定したりしているもの
- OBO (On-Behalf-Of)
- PKCE (Proof Key for Code Exchange)
- BFF (Backend-For-Frontend)
- サービスプリンシパル
おわり
もっと勉強しよう。
Discussion