【ITニュース解説】MCP OAuth 2.1 - A Complete Guide

この記事は、MCP（おそらく、ある種のプラットフォームまたはシステム）の認証方法が、従来のAPIキーベースの方式から、より安全なOAuth 2.1へと進化している状況を解説している。

従来のMCP認証は、クライアント-サーバモデルを採用しており、MCPサーバがリソースの提供と認証の両方を担っていた。これは、システムがモノリシックになり、拡張性、安全性、モジュール性に欠けるという問題があった。クライアントがAPIキーをサーバに送信して認証を行うため、キーが漏洩した場合のリスクも高かった。

OAuth（Open Authorization）は、ユーザがパスワードなどの機密情報を共有せずに、あるアプリケーションから別のアプリケーションのリソースやデータにアクセスできるようにするセキュリティプロトコルだ。OAuth 2.1は、OAuth 2.0をより安全にしたバージョンであり、MCPの認証に適用することで、上記の問題を解決しようとしている。

OAuthの基本的な構成要素は、リソースオーナー（ユーザ）、クライアント（MCPクライアント）、リソースサーバ（MCPサーバ）、そして認証サーバだ。認証の流れは以下のようになる。まず、クライアントはリソースサーバにリクエストを送信する。リソースサーバは、認証が必要な場合、クライアントに認証を促す。クライアントは、認証サーバにリダイレクトされ、ユーザはそこで認証を行う。認証が成功すると、認証サーバはクライアントに認可コードを発行する。クライアントはこの認可コードを認証サーバに提示し、アクセストークンと交換する。クライアントはこのアクセストークンを使って、リソースサーバにリクエストを送信し、リソースにアクセスする。

MCPにおけるOAuth 2.1の導入により、認証サーバが独立し、MCPサーバはリソースの提供に専念できるようになった。認証サーバは、自己ホスト型（MCPサーバに組み込まれる）か、外部プロバイダ（Auth0など）を利用することができる。外部プロバイダを利用する場合、ログイン、同意、トークン発行などの認証に関する処理を外部に委託できるため、開発者は認証の実装・管理の負担を軽減できる。

記事では、OAuth 2.1の具体的な実装例として、サーバ（認証サーバ、リソースサーバ）とクライアントのコード例が示されている。このコード例では、ユーザが一度認証を行うと、クライアントはユーザに代わって安全にMCPツールを呼び出すことができる。

MCP認証の安全性を確保するためのガイドラインも提示されている。PKCE（Proof Key for Code Exchange）の使用、認証サーバのメタデータ（RFC 8414）の共有、ダイナミッククライアント登録の有効化などが推奨されている。また、確立されたプロバイダの利用、適切なスコープの設定、アクセスの監視、定期的なトークンローテーション、安全なストレージなどのベストプラクティスも重要だ。

OAuthの利点として、AIコーディングエージェントがGitHubアカウントにアクセスする場合を例に挙げている。OAuthを使用すると、ユーザはエージェントに必要な最小限の権限のみを付与し、いつでもアクセスを取り消すことができる。これにより、APIキーを使用する場合と比較して、セキュリティが大幅に向上する。

OAuth 2.1の導入は、MCPのセキュリティと拡張性を向上させる重要なステップだ。APIキーベースの認証の脆弱性を解消し、より安全で柔軟なシステムを構築できる。特に、リモート環境やエンタープライズ環境でのMCPの利用においては、委任認証が効率的なソリューションとなる。