OAuthとは何ですか？パスワードを直接第三者アプリケーションに渡すこととどう違いますか？
OAuthは、ユーザーがパスワードを第三者に直接渡すことなく、第三者アプリケーション（MCPコネクタなど）に自分の代わりにあるサービスのデータや機能へのアクセスを許可できるようにする認可プロトコルである。この一連の流れの核心は「トークン」にある。ユーザーが既存の信頼できるID管理システム（自分のGoogleアカウントにログインするなど）を通じて認証を完了すると、そのシステムは範囲が限定されたトークンを第三者アプリケーションに発行する。このトークンは認可された特定の操作にしか使えず、アカウントへの完全なアクセス権ではない。
パスワードを直接渡すこととの最大の違いは、範囲と取り消し可能性にある。パスワードが一度漏洩すれば、アカウント全体の制御権が奪われることになるが、OAuthトークンは特定のデータの読み取りのみ、特定の期間のみ有効といった形で制限でき、ユーザーはいつでもID管理システム上でこのトークンを取り消すことができ、そのためにパスワードを変更する必要もなく、アカウント自体のセキュリティにも影響を与えない。
OAuthはなぜ必要とされ、どんな問題を解決するのですか？
OAuthのような仕組みが存在する前は、第三者アプリケーションがユーザーの別のサービス上のデータにアクセスする必要がある場合、唯一の方法はユーザーにパスワードを直接その第三者に入力させて保存させることだった。これには2つの具体的なリスクが伴う。1つ目は、この第三者が侵害された場合、漏洩するのはユーザーの元のパスワードそのものであり、攻撃者はそのパスワードを使って元のサービス上で何でもできてしまい、範囲は一切制限されない。2つ目は、ユーザーには細かい制御権がなく、「すべて許可する」か「全く使わない」かの選択肢しかなく、読み取りだけを許可して書き込みは許可しない、といった細やかな範囲制限ができない。
OAuthは認可を「パスワードを渡す」ことから「範囲が限定されたトークンを発行する」ことへと変え、まさにこの2つの問題を解決する。トークンを持つ第三者アプリケーションが侵害されたとしても、漏洩するのはそのトークンだけであり、攻撃者にできることは認可された範囲に限定される。さらにユーザーやサービス側はいつでもそのトークンを取り消すことができ、元のパスワードには影響しない。同時にユーザーは認可の瞬間に、具体的にどの権限を開放するのかを確認でき、全か無かではなく、より細やかな判断を下せる。
OAuthは実際にどのように機能し、典型的な認可フローはどのようなものですか？
ClaudeがあるMCPサーバーに接続する例で見てみると、典型的な流れはおおよそ次のようになる。Claudeはまずそのサーバーを呼び出そうとする。相手が認可を要求する場合、認可サーバーの所在情報を伴う「未認可」のレスポンスが返される。次にClaudeは、その認可サーバーが公開しているメタデータを調べ、どの認可方式に対応しているかを把握する。Claudeはこのサーバーの身元を事前に必ずしも把握していないため、まず「動的クライアント登録」を通じて自分自身を相手に登録し、識別子を取得する。その後、実際のユーザーによる認可のステップに入る——ブラウザが画面を開き、ユーザーはそのサービスの自分のアカウントにログインし、どの権限を開放するかを確認する。ユーザーが確認すると、サービス側はClaudeが正式なアクセストークンと交換するための資格情報を発行し、以後このサーバーを呼び出すたびに、このトークンを携えて自分に権限があることを証明する。
このプロセスにはPKCE（Proof Key for Code Exchange）という一般的なセキュリティ機構があり、認可プロセス中の資格情報が伝送途中で傍受され、なりすましに使われることを防ぐ。また、トークンには通常有効期限があり、定期的にローテーションされる。これは1つのトークンが長期間使われ続けることで、漏洩時のリスクにさらされる期間が長くなるのを避けるためである。
OAuthは私にとって実際どんな意味があり、利用者と開発者それぞれの立場で何に注意すべきですか？
もしあなたが一般ユーザーで、Claudeを第三者サービス（コネクタ経由でGmailやSlackに接続するなど）に接続する際に認可画面がポップアップするのを見たなら、それはOAuthフローを経験していることを意味する——その画面に表示されている権限範囲は実際に一度目を通す価値があり、開放しようとしている権限がそのコネクタの実際の機能と合っているかを確認するべきであり、認可画面が出たからといってそのまま確認をクリックするのではない。また、対応するサービスのアカウント設定にいつでもアクセスして、現在どの第三者アプリケーションが認可されているかを確認し、もう不要になったものや疑わしく見えるものを取り消せることも覚えておくとよい。
もしあなたがClaude向けのMCPサーバーを開発する立場であれば、OAuthは現時点で本番環境における標準的な要件である。サーバーが固定のAPIキー認証にしか対応していない場合、claude.aiのウェブ版カスタムコネクタインターフェース（Claude Codeとは異なりOAuthしか受け付けない）を使うユーザーは直接接続できない。OAuth認可を構築するには、正しい形式の認可メタデータ、PKCEの実装、トークンローテーションの仕組みなど、かなり多くの細部を扱う必要がある。ゼロから自作したくない場合は、既存のミドルウェア的な選択肢もいくつか市場にあるが、採用する前に、この仕組みが実際に何を保護しているのか、そして自分のサーバーが現時点でこの標準を満たしているかどうかを理解しておく価値はある。
Claude.aiのウェブ版カスタムコネクタインターフェースはOAuth 2.1認証のみを受け付けており、固定のAPIキーやカスタムヘッダーを直接貼り付けることには対応していない。ユーザーがカスタムコネクタを追加する際、インターフェースはOAuthクライアントIDとクライアントシークレットの入力を求め、実際に完全な認可フローを経る。これが、静的キー認証にしか対応していないサーバーが、Claude.aiのTeam／Enterprise組織の共有コネクタリストに追加できない理由でもある。
The advantage is that users never have to hand a password to a third party — authorization scope can be finely limited and revoked at any time, and leak risk is confined to a single token rather than the whole account; the drawback is that, for developers, building a spec-compliant OAuth authorization server involves a fair number of specific details (metadata format, dynamic client registration, PKCE, token rotation), taking considerably more engineering time than simply implementing a static API key check.