Microsoft 365 の認証と承認を理解する / Understanding Microsoft 365 Authentication and Authorization

第 12 回 JPM365DEV 勉強会 (https://jpm365dev.connpass.com/event/370200/) に登壇したときのスライドです。

Transcript

1. Microsoft 365 の認証と承認を理解する 2025/10/16 第 12 回 JPM365DEV 勉強会
2. 篠原 敬志 (Takashi Shinohara) アバナード株式会社 グループ マネージャー, アジャイル コーチ Microsoft MVP M365 (2018-2026) Microsoft Top Partner Engineer Award (2023) JPM365DEV 運営
3. 本日のアジェンダ 認証と承認 OAuth 2.0 Microsoft ID Platform
4. 認証と承認
5. 認証 (Authentication) とは 認証とは、対象の真正性を確認する行為のこと (Wikipedia より) 情報技術の世界ではその人本人であると確認することを指すことが多い 英語では Authentication だが、長いので AuthN と略されることがある
6. 認証の例 印鑑 過去の記憶 顔
7. 承認 (Authorization) とは 承認とは、一定の行為または事実の存在を許諾または肯定すること (Wikipedia より) 情報技術の世界では特定のリソースへのアクセスを許可することを指すことが多い 英語では Authorization だが、長いので AuthZ と略されることがある 承認は Microsoft の用語で一般的には認可と呼ぶことが多い
8. 承認の例 ホテルの鍵 伝説の剣 チケット
9. 認証と承認の組み合わせ カードの所有 暗証番号の入力 限度額の確認 認証 承認
10. 認証と承認は常にセットではない 合言葉、ZIP ファイルのパスワード、共有 URL など、認証をしない承認もある セキュリティ リスクを伴う可能性があるため注意が必要
11. 情報技術の世界での認証と承認 情報技術の世界では現実世界に比べて本人であることの証明が難しい デジタル情報は簡単に複製が可能 世界中に公開されているため攻撃されるリスクが高い フィッシング、ブルートフォース攻撃、辞書攻撃、マルウェアなど 同じ認証手段 (パスワード) を使っている場合は影響範囲が広い より強固なセキュリティ対策が必要
12. 認証の三要素 所持情報 本人のみ所持可能な物理 的なものによる証明 • パスポート • 運転免許証 • マイナンバー カード • クレジット カード • ハードウェア トークン 知識情報 本人のみ知りうる情報による 証明 • 名前 • 住所 • 電話番号 • 暗証番号 • パスワード 生体情報 本人の身体的な特徴による 証明 • 顔 • 指紋 • 声紋 • 虹彩
13. 多段階認証と多要素認証 複数の認証を組み合わせることでセキュリティは強固になる 多段階認証 複数のステップの認証を組み合わせること (要素の種類は問わない) 例) パスワード (知識情報) + 秘密の質問 (知識情報) 多要素認証 複数の要素の認証を組み合わせること 例) 信頼されたデバイス (所持情報) + 顔 (生体情報)
14. 先進認証 (Advanced Authentication) 従来のパスワード認証に加えて、複数の異なる要素や技術を組み合わせる手法 • パスワードレス認証 (FIDO2、パスキー、セキュリティ キーなど) • 多要素認証 • 生体認証 • リスクベース認証 • 行動認証
15. OAuth 2.0
16. OAuth 2.0 とは Microsoft をはじめとした世界の主要サービスが採用している承認の仕組み マルチ デバイスやマイクロ サービスといったクラウド アプリケーションに適している 誰が、何に、どこまでを明確に制御する OAuth 2.0 をベースとした認証の仕組みとして OpenID Connect (OIDC) がある
17. OAuth 2.0 の仕組み OAuth 2.0 には 4 つのロールが関与する • 承認サーバー • クライアント • リソース オーナー • リソース サーバー
18. わかりにくいので…
19. OAuth 2.0 を現実世界で表現すると 出演者 (リソース オーナー) 依頼 マネージャー (クライアント) 受付 運営会社 (承認サーバー) 発行 入館証 (アクセス トークン) 入場 イベント会場 (リソース サーバー)
20. 承認サーバー ユーザー (リソース オーナー) の認証後にリソースへのアクセ スを許可するトークンを発行する ID プロバイダー (IdP) と呼ばれることがある
21. リソース オーナー リソースを所有するユーザーまたはアプリケーション 保護されたリソース (ユーザー データ) に対してクライアントに よるアクセスを許可する
22. リソース サーバー リソース オーナーのデータをホストするサーバー ほとんどの場合は Web API (代表的なものは Microsoft Graph API)
23. クライアント リソース オーナーの代わりにリソース サーバーにアクセスしてデータを操作するアプリケーション Web アプリ、デスクトップ アプリ、モバイル アプリ、ほかの Web API を呼び出す Web API など
24. アクセス トークン リソース サーバーがクライアントを許可するために使用されるトークン RFC 6749 (The OAuth 2.0 Authorization Framework) では以下のように定義される • リソース サーバー、承認サーバー、クライアントの間でのみ共有されること • 第三者による生成、改変、推測ができないようにすること • クライアントは最小限のスコープで要求できること アクセス トークンの使用方法として Bearer トークンや JWT (JSON Web Token) が使用される 入館証を偽造できないための仕組み
25. JWT (JSON Web Token) 推奨される読み方は jot (ジョット) ヘッダー、ペイロード、署名で構成される • ヘッダー: トークンの種類と署名アルゴリズム • ペイロード: トークンに含まれるクレームのセット • 署名: トークンの改ざんを防ぐための署名
26. クレーム クレーム＝正当な権利の主張 承認に関する発行者、有効期限、ユーザー情報などのデータが含まれる リソース サーバーはクレームを検証することで正当性を確認する クレーム名 説明 実際の例 iss 発行者 (Issuer) https://sts.windows.net/{tenant-id}/ sub 主体 (Subject) vz9jzDIIQQLxgevubSyGmj53MmAmpntekwJ_qJPH3Tg aud 対象 (Audience) 00000003-0000-0000-c000-000000000000 exp 有効終了日時 (Expiration) 1707052800 nbf 有効開始日時 (Not Before) 1707049200 iat 発行日時 (Issued At) 1707049200
27. JWT のデコード JWT をデコードするためのサイト (アクセス トークンの取り扱いには注意！) jwt.io (Auth0 提供) jwt.ms (Microsoft 提供)
28. DEMO jwt.io を使ってアクセス トークンの中身を見る
29. Microsoft ID Platform
30. Microsoft ID Platform とは Microsoft Entra ID (Azure AD) を基盤とする認証基盤 (IdP)
31. アプリケーションの登録 組織の Microsoft Entra ID にアプリケーション登録をすることで独自のアプリケーションに認証お よび承認を実装できる • シングルテナント: 自組織でのみ使用するアプリケーション • マルチテナント: ISV など外部に提供するアプリケーション Azure ポータルまたは Microsoft Entra 管理センターから登録する 以前はマイクロソフト アカウント (個人アカウント) でも登録できたが現在は非推奨
32. 公開クライアントと機密クライアント 公開クライアント 機密クライアント ユーザーのデバイス上で実行され、資格 情報 (クライアント シークレットや証明 書) を保存できないクライアント • シングル ページ アプリケーション • デスクトップ/モバイルアプリ • コンソール アプリ サーバー上で実行され、資格情報 (クラ イアント シークレットや証明書) を保存で きるクライアント • Web アプリ • Web API • デーモン サービス (バッチ プログラム)
33. OAuth 2.0 フロー クライアントのシナリオに合わせてさまざまなフローが存在する (下記は代表的なもの) フロー名 説明 RFC Authorization Code Flow 認可コードを使ったフロー RFC 6749 Authorization Code Flow with PKCE PKCE (Proof Key for Code Exchange) を使ったフロー RFC 7636 Implicit Flow 暗黙的な許可フロー (非推奨) RFC 6749 Client Credentials Flow クライアント資格情報を使ったフロー RFC 6749 Resource Owner Password Credentials Flow パスワード資格情報を使ったフロー (非推奨) RFC 6749 Device Code Flow デバイス コードを使ったフロー RFC 8628 On-Behalf-Of Flow (OBO) 別の API の呼び出しに使われるフロー RFC 8693
34. 委任されたアクセス許可 リソース オーナーの持っているアクセス許可のうち一部のアクセス許可をクライアントに委任する • クライアントはリソース オーナーに許可されていない操作はできない • リソース オーナーがもともと許可されていない操作もできない マネージャー、代わりにやっといて でも言ったこと以外やっちゃダメだよ 出演者 (リソース オーナー) マネージャー (クライアント)
35. アプリケーションのアクセス許可 クライアントそのものに与えられたアクセス許可で動作する 非常に強い権限を持つため限定的なシナリオでのみ使用する 対応しているのは Client Credentials Flow のみ
36. DEMO アプリケーション登録をして Postman から Microsoft Graph API を呼び出す
37. まとめ 認証は本人確認、承認はアクセス許可の仕組み OAuth 2.0 はクラウド アプリケーションの承認の仕組み Microsoft ID Platform を使ってカスタム アプリに OAuth 2.0 を実装できる
38. ご清聴ありがとうございました アンケートのご協力お願いします！ https://forms.office.com/r/VhKmBi10J8