APIキー は、API を呼び出すアプリケーションやプロジェクトを識別するための文字列です。
Google Cloud のドキュメントでも、APIキーはリクエストをプロジェクトへ関連づけ、課金、クォータ、監視などに使うものと説明されています。
大事なのは、APIキーが ユーザー本人を表すものではない ことです。
つまり APIキーは、どのアプリから来たか どのプロジェクトにひもづくか を扱うのには向いていますが、どのユーザーの権限で何をしてよいか を細かく表すのは苦手です。
そのため、APIキーは次のような場面でよく使われます。
実務で大事なのは、APIキーを ログイン手段 として考えないことです。
APIキーはアプリ側の識別には向いていても、ユーザーごとの権限委任や本人確認には向いていません。そのため、ユーザー本人の非公開データ取得や、本人としての更新操作が必要なら、OAuth 2.0 のような別の仕組みを使うほうが自然です。
一方で、ユーザー本人の非公開データへアクセスしたり、本人の代わりに投稿や更新をしたりする用途では、OAuth 2.0 のような委任の仕組みが必要になりやすいです。
APIキーはシンプルで便利ですが、そのぶん運用が雑になりやすい面もあります。
コードへの直書き、環境ごとの使い回し、制限なしの発行は危険です。実務では、API制限、IP制限、HTTPリファラ制限、用途ごとの分離、失効やローテーションを前提に扱うほうが安全です。
また、開発用と本番用で同じキーを使わない、フロントエンドへ露出するキーは使えるAPIを厳しく絞る、漏えい前提で失効できる運用を用意しておく、といった考え方も重要です。
APIキーは手軽ですが、手軽さのぶん制限設計と棚卸しを怠ると事故につながりやすいです。
要するに APIキーは、アプリやプロジェクトを識別するための鍵 であって、ユーザー権限を委任するための仕組み ではありません。
詳しくは APIキーとは？OAuthと何が違うのか で整理しています。