認証という課題
GitHub、Slack、クラウドプロバイダなどに接続するMCPサーバーには資格情報が必要です。これらの資格情報は安全に保管し、安全に送信し、有効期限が切れたら更新しなければなりません。資格情報が漏洩すれば、攻撃者はMCPサーバーが接続するサービスへのアクセスを得てしまうため、これを正しく扱うことは極めて重要です。
MCPプロトコルは特定の認証方式を規定していません。この柔軟性によってサーバー開発者はユースケースに合った方式を選べますが、サーバー間で標準化された認証方式が存在しないという面もあります。
APIキーパターン
最も単純な認証パターンは、環境変数を通じてAPIキーをMCPサーバーに渡す方法です。サーバーは起動時にキーを読み取り、外部サービスへのリクエストに含めます。長期間有効で安定したAPIキーを持つサービスとは相性の良い方式です。
利点はシンプルさです。環境変数を設定し、サーバーを起動すれば、認証は機能します。欠点は、環境変数に保管されたAPIキーがプロセス一覧、ログファイル、設定ファイルの漏洩を通じて露出し得る点です。シェルで直接変数を設定するのではなく、適切なファイルパーミッションを設定した環境変数ファイル(.envなど)を使うようにしましょう。
OAuthフローパターン
OAuthを使うサービス(Google、Microsoft、Slack、GitHub)では、より複雑な認証フローが必要になります。ユーザーはMCPサーバーに自分のアカウントへのアクセスを許可する必要があり、これにはサービスの認可ページへのリダイレクト、許可付与、アクセストークンの受け取りが含まれます。
一部のMCPサーバーは、認可フローの間ローカルなWebサーバーを起動することでこれを処理します。ユーザーがURLを開いて許可を与えると、リダイレクトによってトークンがローカルサーバーに送り返される、という流れです。ユーザーにとっては扱いやすいフローですが、認証ステップのためにMCPサーバーがHTTPサーバー機能を備える必要があります。
別の方式として、ユーザーが一度だけ実行してトークンを取得する独立した認可ツールを使い、取得したトークンをローカルに保存してMCPサーバーが利用するという方法もあります。これは認証の関心事をMCPサーバー本体から切り離せますが、セットアップ手順が一段階増えます。
トークンの更新
OAuthのアクセストークンは有効期限が切れます。期限切れになると、MCPサーバーはユーザーに再認可を求めることなく新しいアクセストークンを取得するために、リフレッシュトークンを使う必要があります。外部サービスへのアクセスを継続的に必要とする長時間稼働のMCPサーバーでは、トークン更新を正しく実装することが重要です。
よくある問題には、トークン更新を一切扱っていない(トークンが切れた瞬間にサーバーが動かなくなる)、トークンを更新するものの新しいトークンを永続化していない(サーバー再起動のたびに再認可が必要になる)、複数リクエストが同時にトークン更新を引き起こしてレースコンディションが発生する、といったケースがあります。
セキュリティのベストプラクティス
資格情報をMCPサーバーのソースコードにハードコードしてはいけません。当たり前に思えるかもしれませんが、これは何度も繰り返されている問題なので明記する価値があります。ソースコードに含まれた資格情報は、バージョン管理にコミットされ、コードレビューを通じて共有され、リポジトリへのアクセスを通じて露出する恐れがあります。
OAuthアクセスを設定する際は、可能な限り制限的なスコープを使いましょう。MCPサーバーがメールを読むだけでよいのなら、メール送信の権限まで要求すべきではありません。スコープを絞っておけば、サーバーが侵害された場合やプロンプトインジェクション攻撃がサーバーの能力を悪用しようとした場合の被害を抑えられます。
トークンは安全な場所に保管しましょう。Keychain連携(macOS)、資格情報マネージャー(Windows)、パーミッションを制限した暗号化ファイル(Linux)はいずれも、平文ファイルよりは優れています。一部のMCPサーバーはこうしたセキュアなストレージバックエンドに対応しているので、より安全性の低い代替手段に頼る前にドキュメントを確認してください。