🐋
🐰 Azure AD × OpenID Connect で「匿名ログイン」を実現するシンプル設計ガイド【企業向けアプリ】
企業システムでよくある要望のひとつに、
「Azure AD ログインは使いたいけど、ユーザーの個人情報はアプリに渡したくない」
というニーズがあります。
🐤 本記事でわかること
- Azure AD の認証だけをアプリに委任する方法
- 個人情報を返さずに 匿名ID だけでユーザー識別する方法
- oid / sub のどちらを使えばよいか
- 実装・設定のポイントがわかる
🐶 なぜ匿名IDが必要なの？
企業向けアプリではこんなニーズが増えています。
- プライバシー配慮で 名前・メールアドレスを扱いたくない
- アプリ側で個人情報管理をしたくない
- 認証は Azure AD に任せたい
- でも 同じ利用者かどうかは識別したい
そんなときに役立つのが 「匿名クレームだけ返す Azure AD 認証」 です。
🐸 OpenID Connect（OIDC）とは？
OIDC は OAuth 2.0 をベースにした 認証用プロトコル です。
- 認証が成功すると ID Token（JWT） が返ってくる
- この中に、ユーザーを識別する ID（oid / sub）が入っている
- アプリはこのトークンの署名を検証するだけで「認証されたユーザー」を扱える
🐤 JWT の仕組みに関しては、こちらの記事を参考にしてください → JWT（JSON Web Token）入門：仕組みと認証の流れをわかりやすく解説
🐰 匿名ログインをどう実現するか？
結論：
Azure AD が返すクレーム（ユーザー情報）を最小限にする
これだけです。
App Registration の設定で、
- 氏名：返さない
- メール：返さない
- 部署：返さない
- 必須の識別子：
oidまたはsubのみ
こうすることで、
アプリは 個人情報を一切持たずに“同じ人"を識別できます。
🐤 認証フロー（Authorization Code Flow）
- アプリで「Azure AD でログイン」
- Azure AD のログイン画面へ移動
- ユーザーがメール＋パスワード＋MFA で認証
- Azure AD がアプリに ID Token を返す
- アプリは署名検証し、
oidorsubをユーザーIDとして扱う
🐸 アプリは個人情報を一切保存しなくてOK！
🐶 匿名IDとして使うクレーム
✔ oid（Object ID）
- Azure AD テナント内で固定の ID
- 同一テナントなら不変
- テナントが変わると別 ID になる
👉 企業内アプリ（シングルテナント）向け
✔ sub（Subject）
- アプリ × ユーザー の組み合わせで一意
- OpenID Connect の標準仕様
- マルチテナント SaaS と相性抜群
👉 複数企業向けアプリ（SaaS）向け
🐰 Azure AD 側の設定
Azure Portal →
Entra ID → App registrations
- アプリの登録
- User attributes & claims で不要なクレームを削除
- 返すのは
oidまたはsubのみにする（可能な範囲で）
※削除不可のクレームはアプリ側で無視。
🐤 アプリ側での実装ポイント
- MSAL などの OIDC ライブラリを利用
- ID Token を検証（署名チェック）
-
oidorsubをユーザーIDとして DB に保存 - アプリ内の権限（管理者/一般など）は DB 管理
- 氏名やメールは保持しない＝匿名性維持 🐶
🐸 最後に決めるべきこと
1. どのクレームを返すか？
- 匿名ログインなら →
oidorsubのみ
2. アプリ内ユーザーIDは何を採用するか？
| アプリタイプ | 推奨ID |
|---|---|
| シングルテナント | oid |
| マルチテナント(SaaS) | sub |
🐰 まとめ
- Azure AD × OIDC で 匿名ログイン は簡単に実現できる
- 「返すクレームを最小限にする」だけ
- アプリは
oidorsubでユーザー識別すればOK - 個人情報を扱わずにセキュアな認証ができる 🐤🐶🐸
Discussion