OAuthとは？AIサービス連携で使われる認可の仕組み

まず結論

OAuth（オーオース）は、利用者が使っている外部サービスへのアクセス権限を、別のアプリケーションへ限定的に委任するための認可の仕組みです。

たとえば、ChatGPTから外部の文書サービスを利用するとき、サービスのパスワードをChatGPTへ教える代わりに、認可画面で「文書の読み取りを許可する」と承認する方式があります。OAuthは、こうしたアクセス許可を扱う標準技術です。

OAuth自体はログイン認証を定義する仕組みではありません。 また、OAuthの採用だけでデータへのアクセスがすべて安全になるわけではなく、認可範囲と接続先サービスの権限チェックが重要です。

定義

OAuthの中心は、パスワードを共有するのではなく、権限を委任することです。

外部アプリに元サービスのIDとパスワードを預けると、文書を読むだけのアプリにアカウント全体のログイン情報を渡しかねません。

OAuthでは、利用者が元サービス側で権限を承認し、接続先アプリは発行されたAccess Tokenを使って認められた範囲のAPIへアクセスできます。ただしAccess Tokenも秘密として保護する必要があります。

仕組み

架空の「文書クラウド」に保存された資料をChatGPTから検索するケースです。

1. 接続開始： ChatGPTで対応する外部アプリを選びます。
2. 確認と承認： 必要に応じて文書サービスへログインし、読み取り権限などの許可内容を確認します。
3. 認可情報の発行： OAuthの手順に従い、アプリがAccess Tokenを取得します。
4. 検索要求： 利用者が「今週の議事録を検索して」と依頼し、許可されたAPIを利用します。
5. 権限確認： 文書サービスはTokenと利用者のアクセス権限を確認して結果を返します。

これは一般的な説明例です。ChatGPTの接続画面や使えるToolはサービス・プランによって異なります。

認証と認可の違い

用語	何を確認するか	例
認証（Authentication）	その人が誰か	ログイン・本人確認
認可（Authorization）	何を許すか	文書の読み取りだけ許可
OAuth	アクセス権の委任を扱う標準	外部アプリの限定アクセス
OpenID Connect（OIDC）	OAuth 2.0を土台とする認証の仕組み	外部アカウントでログイン

「ログインできた」と「その操作が許される」は別です。接続を承認しても、組織内の全データが閲覧できるとは限りません。

OAuthの4つの役割

役割	仕事	文書サービスの例
Resource Owner	リソースへのアクセスを許可する主体	文書を管理する利用者
Client	アクセスを要求するアプリ	AI連携アプリ
Authorization Server	認可・トークン発行	認可サービス
Resource Server	保護されたAPI・データ提供	文書検索API

Authorization ServerとResource Serverは役割の違いであり、必ず別のコンピューターという意味ではありません。

Access Token・Scope・Refresh Token

Access Token：アクセスを許可されたことを示す情報

Clientが保護されたAPIを利用するときに使う認可情報です。Resource Serverは有効期限、対象サービス、権限などを検証します。Tokenはパスワードでなくても秘密情報です。

Scope：委任する権限の範囲

たとえば説明用に documents.read（読み取り）、documents.write（書き込み）といったScopeを考えられます。実際の名前はサービスにより異なります。

検索だけのアプリは、通常書き込み権限まで要求しない方が安全です。ただし、Scopeがあってもすべての文書にアクセスできるとは限らず、個々のデータのアクセス制御が必要です。

Refresh Token：継続利用のための情報

Access Tokenには通常有効期限があり、構成によってはRefresh Tokenで新しいAccess Tokenを取得できます。常に発行されるわけではなく、接続解除・権限取消しの挙動もサービスに依存します。

OAuthとMCPの関係

MCPはAIアプリケーションと外部Tool・データの接続を標準化し、OAuthはそこで必要となる認可を扱える技術です。

ChatGPTからMCP対応の文書検索サービスへ接続する際、MCPがToolの提供と呼び出しを担い、OAuthを用いる構成ではアクセス許可を扱います。

MCPのHTTP認可仕様には、保護されたMCP ServerをResource Serverとし、MCP Clientが適切なTokenを使う構成があります。一方ですべてのMCP接続がOAuth必須というわけではありません。接続方法や仕様版によって異なります。

MCPの仕組みは「MCP完全ガイド」で解説しています。

接続を承認するときの確認

1. どのアプリか： 見覚えのないアプリや紛らわしい名前ではないか。
2. 何を許可するか： 閲覧だけでよいのに変更・削除を要求していないか。
3. 解除できるか： 元サービスで接続や権限を取り消す方法があるか。

AI連携ではTool経由で操作が行われる場合があるので、許可の内容を確認することが重要です。

よく混同される概念

Q. OAuthはログインの仕組みですか？

主目的は認可です。認証にはOIDCなどが使われます。

Q. OAuthで接続すればAIは何でも操作できますか？

いいえ。Tokenの認可範囲とサービス側のアクセス権限に制限されます。

Q. OAuthなら漏えいの心配はありませんか？

いいえ。Tokenを適切に保護する必要があります。

Q. Scopeを増やせばMCPツールが表示されますか？

必ずしもそうではありません。Server接続やTool discoveryなど、別の原因もあります。MCPツールが表示されないときの確認ポイントを参照してください。

OGINAUとの関係

OGINAUではOGINAU RemoteやOGINAU Browserの開発で、AIと外部環境をつなぐ認証・認可を検証しています。

重要なのは、利用者が接続を承認することと、特定の操作を実行できることは別という点です。アプリの接続が完了しても、すべてのファイルや機能を操作できるわけではありません。

本記事では一般化できる知見だけを説明しています。内部の認証構成、トークン管理方法、権限判定の順序は公開していません。

根拠・一次情報

• RFC 6749：The OAuth 2.0 Authorization Framework：OAuthの基本構造。

• RFC 9700：OAuth 2.0 Security Best Current Practice：トークン保護などの安全性。

• OpenID Connect Core 1.0：OAuth 2.0を基盤とする認証。

• MCP Authorization（2026-07-28）：MCPでの認可とOAuth。

• OGINAU Remote・OGINAU Browserの開発検証記録：接続と操作権限を分けた知見。

まとめ

OAuthは、元サービスのパスワードを外部アプリに渡す代わりに、アクセス権限を限定して委任するための認可の標準です。

ポイントは、認証と認可は異なること、Access TokenとScopeには役割があること、OAuthで接続できてもすべての操作が許可されたわけではないことです。