改めて学ぶ認証認可

IDENTITY & ACCESS 改めて学ぶ、認証認可 AIエージェント時代のアクセス管理を、図解でやさしく 認証（AuthN） 認可（AuthZ） あなたは誰？ ＝ 本人確認 何をしてよい？ ＝ 権限の範囲 Microsoft Entra ID × Snowflake × Tableau ／ 委任・最小権限・短命トークン・サービスプリンシパル

1. 認証と認可は『別物』、そして全体像 認証 AuthN ｜ あなたは誰？ 全体像マップ（1枚で） 本人確認。ID＋パスワード＋多要素認証（MFA）や SSO で『本人であること』を 確かめる。 利用者（あなた） ↓ 認可 AuthZ ｜ 何をしてよい？ ① 認証：あなたは誰？ 権限の範囲。ロールで『見られるデータ・できる操作』が決まる。認証済みでも 範囲外はできない。 Microsoft Entra ID（IdP）｜ ログイン・多要素認証・SSO ↓ 本人確認済みの証 ＝ トークン 空港のたとえ：パスポートで本人確認（認証）→ 搭乗券で乗れる便・座席が決ま る（認可）。本物でも搭乗券がなければ乗れない。 ② 認可：何をしてよい？ Tableau Snowflake サイト/PJ 権限 ロール USE/READ/WRITE → 権限はチェイン（実効は本人の範囲内） 認証で本人を確かめ、認可で範囲を決める——この2段構えが全ての土台。 ↓ 代理でアクセス（委任） AIエージェント：あなたの代理（委任・最小権限・短命トークン） 2/7

2. 用語の整理：SSO / SAML / OAuth / OIDC・トークン・スコープ&ロール 規格 役割 ひとことで言うと トークン 役割 たとえ SAML 2.0 認証(SSO) 企業SSOの定番。XMLで『本人です』を証明 IDトークン 誰か(認証結果) 身分証 OAuth 2.0 認可(委任) 『代理でアクセスする許可』を渡す仕組み アクセストークン 何をしてよい(認可) 入館パス(期限付) OIDC 認証 OAuth 2.0 の上に IDトークン(本人確認) を追加 リフレッシュトークン パスの再発行 引換券 ポイント：OAuth 2.0 は本来『認可』の仕組みで『本人が誰か』は伝えない。本人確 認も足したのが OIDC。 スコープ（scope） ロール（role） トークン側に持たせる『できることの範 囲』。例：read:invoices（請求書の閲覧 のみ） 利用者側に割り当てる『権限のまとまり 』。例：Snowflake の ANALYST ロー ル SSO＝一度のログインで複数サービスへ再ログインなしで入れる仕組み。 3/7

3. ログインの流れ：Entra ID × Snowflake の SSO と、OAuth の登場人物 ① SSO：Entra ID で Snowflake にログイン（認証） ② OAuth 2.0：4人の登場人物（＝委任） ① Snowflake（SP）にアクセス 役割 今回の例 リソース所有者（データの持ち主） 利用者 クライアント（代わりに使うアプリ） Tableau 認可サーバー（許可を判断・発行） Entra ID リソースサーバー（データを持つ） Snowflake ② Entra ID（IdP）へリダイレクト ③ ログイン＋多要素認証（＝認証） ④ 認証成功 ＝ SAMLアサーション発行 ⑤ Snowflake がアサーションを検証し本人を特定 ⑥ 割り当てロールの権限で利用（＝認可） 本人確認は Entra ID に集約（MFA・条件付きアクセス）。 OAuth は『代理でアクセスする許可』を渡す＝委任。アプリにパスワードは 渡さず、用途と期限が限定されたトークンだけを渡す。 4/7

4. サービスをまたぐ認可：Tableau → Snowflake（外部OAuth） Tableau → Entra ID → Snowflake の流れ ① 利用者：Snowflake のデータに接続したい 権限のチェイン：実効権限は必ず本人の範囲内 利用者本来の権限（上限・起点） ② Tableau：Entra ID へ OAuth 認可を要求 ③ Entra ID：ログイン＋同意【認証】→ トークン(JWT)発行 ④ Tableau：トークンを付けて Snowflake へ接続 Tableau 権限 Snowflake 権限 サイト / プロジェクト USE / READ / WRITE ⑤ Snowflake：トークンを検証し利用者に対応づけ ⑥ Snowflake：そのロール権限でデータ返却【認可】 実効権限 ＝ 両方の重なり かつ 必ず枠の内側 各サービスの権限は別物。サービスが増えても、本人の範囲を一つでも超えたら 不可（＝鎖は一番狭い輪まで）。 認証 ＝ Entra ID ／ 認可 ＝ Snowflake のロール(RBAC)。役割がきれいに 分かれる。 5/7

5. AIエージェント／サービスプリンシパルの権限管理 混乱した代理人問題：強い権限を持つ代理人が、悪意ある入力（プロンプトインジェ クション等）にだまされ、その権限を悪用してしまう危険。 サービスプリンシパル：便利だが逸脱に注意 いつ使う：接続先の仕様上 個人トークンが使えない／運用上 権限の細分化が難しい。人 もAIも起こりうる。 だから 3原則 ＋α 最小権限：必要な操作だけ（集計なら閲覧のみ） 委任(On-Behalf-Of)：利用者の代理と明示、本人の範囲を超えない 短命トークン：期限を短く、漏れても被害を最小化 エージェント専用ID：人と共有せず、監査で操作主体を区別 利用者本来 の権限 共通 ＝OK サービス プリンシパル 権限 人の承認：重要操作は Human-in-the-Loop ← はみ出し ＝ 要確認（利用者権限の逸脱） 鉄則：本人の権限範囲を逸脱していないか必ず確認・制御（最小権限・代理の記 録・二重確認）。 6/7

まとめ：認証／認可 早見表・要点・参考リンク テーマ 認証（あなたは誰？） 認可（何をしてよい？） 押さえる3点 空港のたとえ パスポート 搭乗券 ① 認証と認可は別物 規格 SAML / OIDC OAuth 2.0 ② 連携は役割分担（本人確認＝IdP／範囲＝サービス） ③ 代理に万能の鍵を渡さない（最小権限・逸脱確認） トークン IDトークン アクセストークン Entra ID × Snowflake Entra ID が本人確認 Snowflake のロールで範囲 Tableau → Snowflake Entra ID が本人確認 Snowflake の RBAC で範囲 AIエージェント 専用IDで識別 最小権限＋短命＋人の承認 参考リンク（一次情報） 複数サービス連携 各サービスで本人確認 本人の範囲内でチェイン サービスプリンシパル 誰の代理か記録 逸脱を必ず確認 RFC 6749（OAuth 2.0） OpenID Connect Core 1.0 SAML v2.0（OASIS） Snowflake：External OAuth（Entra ID） Snowflake：SSO with Entra ID Tableau：Snowflake OAuth 接続 Microsoft：On-Behalf-Of flow Model Context Protocol：Authorization 7/7

• https://www.rfc-editor.org/info/rfc6749/
• https://openid.net/specs/openid-connect-core-1_0.html
• https://www.oasis-open.org/standard/saml/
• https://docs.snowflake.com/en/user-guide/oauth-azure
• https://learn.microsoft.com/en-us/entra/identity/saas-apps/snowflake-tutorial
• https://help.tableau.com/current/pro/desktop/en-us/snowflake_oauth.htm
• https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-on-behalf-of-flow
• https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization