まえがき

　業務システムは複数のクラウドサービスを組み合わせて構成されることが一般的になりつつある．また，大規模言語モデルを基盤とするAIエージェント（以後，エージェント）が，利用者に代わって複数のシステムを横断的に操作する事例も増えている．このような環境では，「誰が本人確認を行い，誰がどこまでの操作を許可するのか」を正しく設計できることが，従来にも増して重要になっている．

　一方で，実務の現場では，認証（Authentication，以後 AuthN）と認可（Authorization，以後 AuthZ）がしばしば混同される．ログイン（認証）が完了したことと，そこで何をしてよいか（認可）は本来別の問題であるが，両者を一体のものとして扱ってしまう例は少なくない．この混同は権限設計の見通しを悪くし，結果として過剰な権限付与や情報漏えいの温床となりうる．

　本記事では，認証と認可の違いを起点として，SSO（Single Sign-On）やOAuth 2.0といった基盤技術，Microsoft Entra ID（以後 Entra ID）とSnowflakeを用いたシングルサインオン，TableauからSnowflakeへの外部OAuth接続，そしてエージェント時代の権限管理までを，初学者にも追える形で整理する．なお，本記事に掲載する図は別途作成したスライド資料（PowerPoint版）と対応しており，Qiita上で表示できるようMermaid記法で再構成したものである．

　本記事は全7章から構成される．各章の内容は次のとおりである．第1章では認証と認可の違いを整理する．第2章では基盤となる用語と全体像を示す．第3章ではEntra IDとSnowflakeによるSSOを，第4章ではOAuth 2.0の全体像を述べる．第5章ではサービスを横断する認可として，TableauからSnowflakeへの接続と権限のチェインを扱う．第6章ではエージェントの権限管理を，第7章ではサービスプリンシパルを用いる場合の注意点を述べる．最後にまとめと参考文献を示す．

　本記事は，改めて学ぶ認証認可にまとめているため，本記事と合わせて読んでいただけると幸いである．

1. 認証と認可は別の概念である

　はじめに，最も基本的な区別を明確にする．認証と認可はしばしば一括りに語られるが，その役割は明確に異なる．認証（AuthN）は「あなたは誰か」を確かめる本人確認の手続きであり，認可（AuthZ）は「何をしてよいか」を定める権限付与の手続きである［1］．

　この違いは，空港での手続きにたとえると理解しやすい．パスポートによる本人確認が認証に，搭乗券による搭乗の可否・座席の決定が認可に対応する（図1）．パスポートが本物であっても，搭乗券がなければ搭乗はできない．すなわち，「本人であると確認できたこと」と「その人が何をしてよいか」は別の事柄である．

図1　認証と認可の関係（空港のたとえ）

　したがって，「ログインができたのだから，あとは自由に操作してよい」という理解は誤りである．正しくは，認証によって本人を確かめたうえで，操作ごとに「それを行ってよいか」を認可によって判定する．この2段構えが，以降で述べるすべての仕組みの土台となる．

2. 基盤となる用語と全体像

　本章では，以降の説明で用いる用語を整理し，記事全体の全体像を示す．

　まず，登場する主体として，本人確認を担うIdP（Identity Provider，以後 IdP）と，利用したいサービスであるSP（Service Provider，以後 SP）がある．Entra IDはIdPの，SnowflakeはSPの代表例である．次に，本人確認の結果を複数サービス間で受け渡す仕組みとしてSSOがある．SSOは，一度のログインで複数のサービスに再認証なしでアクセスできる仕組みである．

　認証・認可に関わる規格として，SAML 2.0，OAuth 2.0，OpenID Connect（以後 OIDC）の3つを区別しておく．表1にそれぞれの役割を示す．重要な点として，OAuth 2.0は本来「認可」の仕組みであり，「利用者が誰か」を伝えることを目的としていない［2］．本人確認の機能をOAuth 2.0の上に加えたものがOIDCである［3］．

表1　認証・認可に関わる主な規格

規格	主な役割	概要
SAML 2.0	認証（SSO）	企業向けSSOで広く用いられる．XMLで本人であることを表明する［4］
OAuth 2.0	認可（委任）	「代理でアクセスする許可」を渡す仕組み［2］
OIDC	認証	OAuth 2.0 の上にIDトークン（本人確認）を加えたもの［3］

　さらに，サービス間で認証・認可の結果を受け渡す媒体としてトークンがある．表2に主要なトークンを示す．

表2　主要なトークン

トークン	役割	たとえ
IDトークン	「誰か」を伝える（認証の結果）	身分証
アクセストークン	「何をしてよいか」を伝える（認可）	有効期限付きの入館証
リフレッシュトークン	アクセストークンの再取得に用いる	入館証の引換券

　権限を表す概念として，スコープとロールを区別する．スコープ（scope）はトークンに紐づく「できることの範囲」であり，ロール（role）は利用者やサービスに割り当てる「権限のまとまり」である．両者を組み合わせて「誰が，何を，どこまで行えるか」が定まる．

　以上を1枚にまとめると，記事全体の地図が得られる（図2）．左側の認証で「あなたは誰か」を確かめ，右側の認可で「何をしてよいか」を定める．エージェントは利用者の代理として，この地図の上を最小限の権限で動く．

図2　全体像マップ（登場人物と認証・認可の役割）

3. Entra ID と Snowflake によるシングルサインオン

　本章では，具体例として，Entra IDを用いてSnowflakeにシングルサインオンする構成を述べる．これは主に認証（SSO）に関する話題である．ここでSnowflakeはSP，Entra IDはIdPとして機能する．設定手順の詳細は公式ドキュメントにまとめられている［5］．

　処理の流れを図3に示す．利用者がSnowflakeにアクセスすると，SnowflakeはEntra IDへのリダイレクトを返す．利用者はEntra ID上でログインと多要素認証を行い，認証に成功するとSAMLアサーションが発行される．Snowflakeはこのアサーションを検証して利用者を特定し，割り当てられたロールの権限の範囲で利用を許可する．

図3　SSO によるログインの流れ（Entra ID × Snowflake）

　ここで役割の分担を確認しておく．本人確認（認証）はEntra IDが担い，何をしてよいか（認可）はSnowflakeがロールに基づいて判定する．すなわち，「誰か」の確認はIdPに，「何をしてよいか」の判断はサービス側に分かれている．この分担により，パスワード管理や多要素認証をEntra IDに集約でき，Snowflakeはロール設計（RBAC）に基づく認可に専念できる．なお，利用者アカウントをEntra IDからSnowflakeへ自動で同期する仕組み（SCIMによるプロビジョニング）を併用すると，アカウント管理の負担を軽減できると考えられる．

4. OAuth 2.0 の全体像

　サービスを横断する連携の中心となるのがOAuth 2.0である［2］．その要点は委任（delegation），すなわち「利用者の代わりに，限られた範囲でアクセスしてよい」という許可を渡す考え方にある．

　OAuth 2.0には4つの主体が登場する．データの持ち主であるリソース所有者（Resource Owner），代理でアクセスするアプリであるクライアント（Client），許可を判断してトークンを発行する認可サーバー（Authorization Server），データを保持するリソースサーバー（Resource Server）である．後述するTableau・Snowflakeの例では，順に利用者，Tableau，Entra ID，Snowflakeが対応する．

　基本的な流れを図4に示す．利用者の同意に基づき，認可サーバーがアクセストークンを発行し，クライアントはそのトークンを用いてリソースサーバーにアクセスする．重要な点として，クライアントに渡すのはパスワードではなく，用途と有効期限が限定されたトークンのみである．これにより，安全に代理アクセスを実現できる．

図4　OAuth 2.0 の基本的な流れ（委任）

5. サービスを横断する認可（Tableau から Snowflake への接続）

　本章では，本記事の主題の1つである，TableauからOAuthを用いてSnowflakeに接続する構成（本人確認はEntra IDが担う）を述べる．この例では，「認証はEntra ID，認可はSnowflake」という役割分担が明確に現れる．

　この構成は，Snowflakeにおいて外部OAuth（External OAuth）と呼ばれる方式である［6］［7］．外部の認可サーバーであるEntra IDが発行したトークンを，Snowflakeが信頼して受け入れる点が特徴である．Tableau側の接続設定は公式ドキュメントに示されている［8］．

　処理の流れを図5に示す．利用者がSnowflakeのデータへの接続を要求すると，TableauはEntra IDにOAuth認可を要求する．利用者はEntra ID上でログインと同意を行い（ここが認証である），Entra IDはアクセストークン（JWT）を発行する．Tableauはこのトークンを付与してSnowflakeへ接続を要求し，Snowflakeはトークンを検証したうえで，トークン内のクレーム（利用者の属性情報）をSnowflake上の利用者に対応づける．そして，その利用者に割り当てられたロールの権限の範囲でのみデータを返す（ここが認可である）．

図5　Tableau から Snowflake への外部 OAuth 接続の流れ

　この構成の要点は，認証と認可が別の場所で担われていることである．本人であるかの確認はEntra IDが行い，そのデータを閲覧してよいかの判断はSnowflakeのロール（RBAC）が行う．したがって，Entra IDで認証さえ通れば，Snowflake上のあらゆるデータが見えてしまうということは起こらない．

権限は別々に管理されるが，本人の権限の範囲を超えてはならない

　ここで，実務上とくに重要となる点を補足する．Tableau Server側の権限とSnowflake側の権限は，別々に管理される．具体的には，Tableau Serverの権限はサイトやプロジェクトの単位で「どのワークブックを閲覧・発行できるか」「どのデータソースに接続できるか」を定め，Snowflakeの権限はロールによって「どのデータベース・スキーマ・テーブルに対して USE／READ（SELECT）／WRITE（INSERT・UPDATE 等）を行えるか」を定める．

　これら2つは連動しない別個の仕組みである．しかしながら，両者に共通して守るべき原則がある．すなわち，実際に行える操作（以後，実効権限）は，必ず利用者本人が認証・認可によって許された権限の範囲内に収まっていなければならない．Tableauで閲覧できる範囲とSnowflakeで操作できる範囲の両方を満たし，かつ本人の許可範囲を超えない部分のみが，実際に行える操作となる．

　さらに，間に介在するサービスが増えると，権限は連鎖（以後，チェイン）する．各サービスで権限を確認しながら受け渡していくが，そのいずれか1つでも本人の範囲を超えた時点で，その操作は許されるべきではない．これは，鎖全体の強さが最も弱い輪によって決まることに似ている．図6にこの関係を示す．

図6　権限のチェイン（実効権限は利用者本来の権限の範囲内に収まる）

6. AIエージェント時代の権限管理

　これまで述べた「認証は誰か」「認可は何をしてよいか」「委任は代理でアクセスすること」という枠組みは，エージェントを扱う際にもそのまま当てはまる．むしろ，エージェントにおいてこそ重要になる．

　従来のアプリケーションは，あらかじめ定められた処理のみを行う．一方で，エージェントは利用者に代わって自律的に判断し，複数のシステムを操作する．ここで問題となるのが，混乱した代理人問題（Confused Deputy）である［11］．これは，強い権限を持つ代理人が，悪意ある指示や巧妙な入力（プロンプトインジェクション等）によって欺かれ，その権限を意図しない用途に用いてしまう危険を指す．たとえば，エージェントに広範な権限を与えると，不正な依頼によって機密データの持ち出しや削除が代理で実行されうる．

　したがって，エージェントに対しては次の考え方で権限を渡すことが望ましい．

最小権限の原則（Least Privilege）：業務に必要な権限のみを渡す．たとえば集計のみを行うのであれば，閲覧（read）の権限で足りる．
委任（On-Behalf-Of）：エージェントは利用者になりすますのではなく，「利用者の代理」であることを明示したトークンを用い，スコープを絞って本人の権限を超えないようにする．
短命トークン（Short-lived Token）：トークンの有効期限を短くし，万一漏えいした場合の影響範囲を最小化する．

　この「本人の権限の範囲を超えない」という考え方は，MicrosoftのOn-Behalf-Of（委任）フローにも明確に現れている［9］．そこでは，権限は委任スコープとして渡され，ロールは利用者本人に紐づいたまま（代理するアプリ側には付与されない）とされている．これは，利用者が本来アクセスできない資源にアクセスできてしまうことを防ぐための設計である．委任の流れを図7に示す．

図7　AIエージェントの委任（On-Behalf-Of）の流れ

　加えて，エージェントには専用のアイデンティティ（Entra IDにおけるサービスプリンシパルやマネージドID）を持たせることが望ましい．人間のアカウントを共有させないことで，操作の主体が人間かエージェントかを監査ログ上で区別でき，またエージェント単位で権限を制限・停止できる．さらに，送金・データ削除・外部送信などの重要な操作については，実行前に人間の承認を挟む（Human-in-the-Loop）ことが望ましい．

　最近では，エージェントの安全な連携に関する標準化も進んでいる．たとえば，エージェントが外部ツールに接続するためのMCP（Model Context Protocol）では，OAuth 2.1を基盤とした認可の枠組みが採用されている［10］．「本人確認（認証）」と「範囲を絞った許可（認可）」を分けるという原則は，AI時代においても変わらない．むしろ，エージェントが自律的に動作する分だけ，「誰の権限で，どこまで行うか」を厳密に設計することが，従来以上に求められていると考えられる．

7. サービスプリンシパルを用いる場合の注意点

　前章までは，利用者本人の権限の範囲内で処理が行われることを前提としてきた．しかしながら実務では，利用者個人ではなく，サービス自身の権限（サービスプリンシパル）を用いて処理を実行せざるを得ない場合がある．サービスプリンシパルとは，人ではなくアプリやサービスに割り当てる実行用のIDである（Entra IDのサービスプリンシパルや，データ基盤のサービスアカウント等がこれにあたる）．

　このような実行形態は，エージェントの利用に限らず，人による利用でも生じうる．具体的には，接続先サービスの仕様上，個人の委任トークンを利用できずサービス用のIDでしか接続できない場合や，設計・運用の都合上，権限を個人単位まで細分化することが難しい場合などが挙げられる．そのため，サービスプリンシパルの利用は，時に避けがたい．

　一方で，サービスプリンシパルは個人よりも広い（強い）権限を持つことが多い．そのため，その強いIDを介して，本来その利用者には許されていない操作までが実行できてしまう恐れがある．これは第6章で述べた混乱した代理人問題と地続きの課題である．したがって，サービスプリンシパルを用いる場合であっても，本来の利用者に許された権限の範囲を逸脱していないかを必ず確認・制御することが求められる．具体的には，次のような対策が挙げられる．

サービスプリンシパルの権限を，用途に必要な最小限に絞る．
「誰の代わりに実行しているのか」を記録し，共有IDであっても利用者との対応づけを監査可能にする．
可能であれば，利用者本人の権限で一度検査したうえで，サービスプリンシパルで実行する（権限の二重確認）．
重要な操作については，人間の承認を挟む．

　この関係を図8に示す．利用者本来の権限を大きな集合として起点に置くと，サービスプリンシパルの権限のうち，その集合の内側に収まる部分のみを用いるのが本来の姿である．集合からはみ出した部分は利用者権限の逸脱にあたり，「本当に用いてよいのか」を常に検証すべき領域となる．

図8　サービスプリンシパル権限と利用者本来の権限の関係

まとめ

　本記事では，認証と認可の違いを起点として，SSO，OAuth 2.0，Entra IDとSnowflakeによるSSO，TableauからSnowflakeへの外部OAuth接続，そしてエージェント時代の権限管理までを整理した．要点を表3にまとめる．

表3　認証／認可の早見表

テーマ	認証（あなたは誰か）	認可（何をしてよいか）
空港のたとえ	パスポート	搭乗券
規格	SAML／OIDC	OAuth 2.0
トークン	IDトークン	アクセストークン
Entra ID × Snowflake	Entra IDが本人確認	Snowflakeのロールで範囲を決定
Tableau → Snowflake	Entra IDが本人確認	SnowflakeのRBACで範囲を決定
AIエージェント	専用IDで識別	最小権限・短命トークン・人の承認
複数サービス連携	各サービスで本人確認	本人の範囲内でチェイン
サービスプリンシパル	誰の代理かを記録	逸脱を必ず確認

　本記事の主張は次の4点に集約される．第1に，認証と認可は別の概念であり，「本人確認」と「行ってよいこと」を分けて考える必要がある．第2に，サービスを横断する連携では役割が分担され，本人確認はIdP（Entra ID）が，データの許可範囲はサービス（Snowflake）が担う．第3に，エージェントには広範な権限を与えず，必要最小限・有効期限付き・代理であることを明示したうえで，重要な操作には人間の承認を挟むことが望ましい．第4に，サービスを横断すると権限はチェインするため，各サービスの権限が別管理であっても，実効権限は必ず利用者本人の範囲内に収める必要がある．

　なお本記事は，概念の理解を目的とした整理であり，実際の構成にあたっては各サービスの最新の仕様・要件に従う必要がある．また，ここで述べた設計指針は一般的な原則であり，個々のシステムの要件によっては追加の検討が必要になると考えられる．

　本記事は，改めて学ぶ認証認可にまとめているため，本記事と合わせて読んでいただけると幸いである．

参考文献

［1］ Microsoft，「Authentication vs. authorization」，https://learn.microsoft.com/en-us/entra/identity-platform/authentication-vs-authorization
［2］ IETF，「RFC 6749: The OAuth 2.0 Authorization Framework」，https://www.rfc-editor.org/info/rfc6749/
［3］ OpenID Foundation，「OpenID Connect Core 1.0」，https://openid.net/specs/openid-connect-core-1_0.html
［4］ OASIS，「Security Assertion Markup Language (SAML) v2.0」，https://www.oasis-open.org/standard/saml/
［5］ Microsoft，「Configure Snowflake for Single sign-on with Microsoft Entra ID」，https://learn.microsoft.com/en-us/entra/identity/saas-apps/snowflake-tutorial
［6］ Snowflake，「Configure Microsoft Entra ID for External OAuth」，https://docs.snowflake.com/en/user-guide/oauth-azure
［7］ Snowflake，「Introduction to OAuth」，https://docs.snowflake.com/en/user-guide/oauth-intro
［8］ Tableau，「Configure External OAuth for Snowflake Connections」，https://help.tableau.com/current/pro/desktop/en-us/snowflake_oauth.htm
［9］ Microsoft，「Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow」，https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-on-behalf-of-flow
［10］ Model Context Protocol，「Authorization」，https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
［11］ Wikipedia，「Confused deputy problem」，https://en.wikipedia.org/wiki/Confused_deputy_problem