【ITニュース解説】3 Gotchas When Calling an IAP‑Protected Cloud Run API from a Chrome Extension (MV3)

ニュース記事のタイトルにある「IAP保護されたCloud Run APIをChrome拡張機能から呼び出す際の3つの注意点」について、システムエンジニアを目指す初心者にも理解しやすいように解説する。

まず、基本的な用語から説明する。「Cloud Run」は、Google Cloudが提供するサービスで、サーバーの管理をほとんど意識することなく、WebアプリケーションやAPIを簡単に実行できる。コードをデプロイするだけで、Googleが自動的にスケーリング（負荷に応じてリソースを増減させること）してくれる。「API（Application Programming Interface）」は、ソフトウェア同士が情報をやり取りするための取り決めや窓口のようなものだ。Webサイトやアプリは、このAPIを通じて様々な機能を利用したり、データを受け取ったりする。「Chrome拡張機能」は、Google Chromeブラウザに追加できる小さなプログラムで、ブラウザの機能を拡張したり、特定の作業を自動化したりする。「IAP（Identity-Aware Proxy）」は、Google Cloudのセキュリティサービスで、特定のユーザーしかCloud Runなどのリソースにアクセスできないようにする仕組みだ。これにより、アプリケーションの前にセキュリティゲートを設置し、認証されていないユーザーからのアクセスを防ぐ。

今回の解説は、ユーザーが作成したChrome拡張機能から、IAPによって保護されたCloud Run上のAPIに安全にアクセスする方法と、その際に陥りやすい落とし穴（Gotchas）について深く掘り下げるものだ。システムがセキュアなAPIと通信するためには、通信する側が「誰であるか」を証明する必要があり、この証明が「認証」だ。

一つ目の重要なステップは、Chrome拡張機能からGoogleの「IDトークン」を取得することだ。IDトークンは、ユーザーが特定の人物であることをGoogleが保証するデジタル証明書のようなものだ。拡張機能は、このトークンを使って自分自身（より正確には、そのトークンを持つユーザー）をCloud Run APIに証明する。トークンを取得するために、Chrome拡張機能はchrome.identity.launchWebAuthFlowという特別なAPIを利用する。これは、Googleの認証画面をブラウザにポップアップ表示させ、ユーザーがGoogleアカウントでログインすることを促す機能だ。ユーザーがログインに成功すると、Googleは拡張機能にIDトークンを返す。このプロセスでは、client_id（拡張機能がGoogleに登録されていることを示すID）やredirect_uri（認証後にトークンを返すアドレス）などの情報が正確に設定されている必要がある。特にredirect_uriはchrome.identity.getRedirectURL()で取得できる、拡張機能専用のアドレスを使う。また、トークンには有効期限があるため、毎回取得し直すのは効率が悪い。そこで、取得したトークンを一時的にChromeのローカルストレージに保存し、期限が切れるまで再利用する「キャッシュ」の仕組みが提案されている。このキャッシュは、トークンの有効期限が切れる数分前（記事では5分前）に新しいトークンを取得し直すように設定することで、API呼び出し中にトークンが失効するのを防ぐ。

二つ目のステップは、取得したIDトークンを使ってCloud Run上のAPIを呼び出すことだ。Chrome拡張機能のユーザーインターフェース（popup.jsなど）から、このトークンをバックグラウンドスクリプト（background.js）に要求する。バックグラウンドスクリプトは、先に説明したキャッシュからトークンを返すか、新たに取得して返す。トークンを受け取った拡張機能は、Web APIを呼び出すための標準的な手段であるfetch関数を使って、Cloud Run上のAPIにリクエストを送信する。この際、最も重要なのはHTTPリクエストの「Authorization」ヘッダーに、取得したIDトークンを「Bearer 」という形式で含めることだ。Authorization: Bearer <IDトークン>という形式で送信することで、Cloud RunのIAPは、このリクエストが正当なユーザーから送られてきたものであると判断できる。

三つ目のステップは、Cloud Run上で動作するAPIが、受け取ったIDトークンを検証することだ。APIは、リクエストのAuthorizationヘッダーからIDトークンを抽出し、それが本当にGoogleによって発行されたものであり、改ざんされていないこと、そして意図されたユーザーからのものであることを確認する必要がある。この検証には、Googleが提供するライブラリ（PythonのFlaskアプリケーションの場合、google.oauth2.id_tokenなど）が使われる。検証の際に特に重要なのは「オーディエンス（audience）」という概念だ。オーディエンスは、そのIDトークンが「誰のために発行されたか」を示す情報だ。IAP保護されたCloud Runの場合、このオーディエンスにはIAPのOAuthクライアントIDを指定する必要がある。もし拡張機能が送ってきたトークンのオーディエンスが、APIが期待するIAPのオーディエンスと異なっていた場合、APIはトークンを無効とみなし、アクセスを拒否する。これにより、たとえ有効なトークンであっても、それが別の目的のために発行されたものであれば、保護されたAPIへのアクセスはできないようになっている。トークンが正しく検証されれば、APIはトークンに含まれるユーザー情報（例えばメールアドレス）を取り出して、ビジネスロジックを実行できる。

これらのステップを踏む際に、いくつか注意すべき一般的な落とし穴がある。まず、「401エラー」が発生した場合、多くはサーバー側でのIDトークン検証時の「オーディエンスの不一致」が原因だ。これは、APIが期待するIAP_AUDIENCE（IAPのOAuthクライアントID）と、IDトークンに埋め込まれているオーディエンスが一致しない場合に起こる。開発者は、IAPのOAuthクライアントIDを環境変数としてAPIに正しく設定する必要がある。次に、getIdToken関数が「空のid_token」を返すことがある。これは、Google Cloudプロジェクトで設定されたOAuth2クライアントのタイプが「Webアプリケーション」ではない場合や、認証フローのリダイレクトURIがchrome.identity.getRedirectURL()で取得したものと一致しない場合に発生しやすい。OAuth2クライアントの正しい設定と、リダイレクトURIの一致を確認することが重要だ。また、API呼び出し中に「トークンが期限切れになる」問題もある。これは、先述のキャッシュ戦略で、有効期限よりも十分に早くトークンを更新するように設定することで回避できる。記事では5分間のバッファを推奨している。最後に、Chrome拡張機能の種類によっては「CORS（Cross-Origin Resource Sharing）」の問題が発生することがある。これは、ウェブページのJavaScriptが、異なるドメイン（起源）にあるリソースにアクセスしようとしたときに発生するセキュリティ制限だ。拡張機能がコンテンツスクリプト（ウェブページに直接挿入されるスクリプト）やWebページからAPIを呼び出す場合、API側でAccess-Control-Allow-OriginヘッダーとAuthorizationヘッダーの許可を設定する必要がある。

このように、Chrome拡張機能からIAP保護されたCloud Run APIに安全にアクセスするには、IDトークンの取得、APIリクエスト時のトークン付与、そしてサーバー側での厳格なトークン検証という一連の流れを正確に理解し、実装する必要がある。これらの注意点を把握することで、セキュアで信頼性の高いシステムを構築できるだろう。