APIキーとOAuthの違い認証方式の選び方と漏えい対策
APIキーとOAuthの違いを、誰が呼び出したかの証明・権限の細かさ・漏えい時の影響で比較します。Google Cloudの公式ドキュメントをもとに、使い分けの基準とキーの管理方法を整理します。
公的機関・公式資料などの一次情報と照合して作成しています。このサイトについて
APIキーとOAuthの違いとは
APIを使うには、呼び出す側が誰なのかを、サービス側に示す必要があります。これが認証です。代表的な方式に、APIキーと OAuth があり、SaaSの連携で、どちらを求められるかによって、準備や安全管理の方法が変わります。
Google Cloud の公式ドキュメントでは、APIキーは、リクエストを Google Cloud のプロジェクトに結びつけ、課金や利用の上限の管理に使う文字列と説明されています。標準のAPIキーは、利用者個人を認証するものではなく、権限の確認（IAM）の対象にならない、とも記載されています。一方、OAuth 2.0 は、利用者がログインしてアプリへの権限を許可する同意を得たうえで、アクセストークンを発行する方式です。
基本（2つの方式の違い）
| 観点 | APIキー | OAuth 2.0 |
|---|---|---|
| 仕組み | 固定の文字列を、リクエストに付ける | 利用者の同意を得て、期限つきのアクセストークンを発行する |
| 誰として動くか | 利用者個人を特定しない（標準のキー） | 同意した利用者の権限で動く |
| 権限の細かさ | 粗い。キーごとの制限で絞る | スコープで、許可する範囲を細かく指定できる |
| 期限 | 通常は無期限（再発行まで） | アクセストークンは期限があり、更新用のトークンで延長する |
| 向く用途 | 公開情報の取得、簡単な利用、試験的な利用 | 利用者のデータにアクセスする連携 |
| 漏えい時のリスク | キーを知る誰でも使える | 範囲と期限が限定されやすい |
Google のOAuthの説明では、基本の流れは、認証情報の取得、アクセストークンの取得（利用者が同意）、許可された範囲（スコープ）の確認、トークンを付けたAPIの呼び出し、期限後のトークンの更新、という手順です。また、スコープは、必要になったときに段階的に要求することが勧められています。
APIキーとOAuthの違いの具体例
選び方の例です。
| 場面 | 向いている方式 | 理由 |
|---|---|---|
| 公開された地図や天気の情報を、サイトに表示する | APIキー | 特定の利用者のデータは扱わない |
| 利用者のカレンダーやメールにアクセスするアプリ | OAuth | 利用者の同意と、範囲の限定が必要 |
| 社内の自動化で、サービスの管理操作を行う | OAuthやサービスアカウントなど、より厳密な方式 | 権限の細かい管理が必要 |
| 開発中に、簡単に動作を試す | APIキー | 準備が簡単（本番は別途検討） |
APIキーを使う場合の安全対策は、Google Cloud の「APIキー管理のベストプラクティス」に具体的に記載されています。キーに制限（APIの種類、使える場所＝ウェブサイト・IPアドレス・アプリ）を追加すること、クエリパラメータでキーを渡さないこと、不要なキーを削除すること、画面側のコードやリポジトリにキーを入れないこと、監視とログを強化すること、定期的に入れ替えることなどです。あわせて、より安全な認可方法（IAMポリシーと短期間有効なサービスアカウントの認証情報など）の検討も勧められています。
APIキーとOAuthの違いの実践ステップ
- 使いたいAPIの公式ドキュメントで、対応する認証方式を確認する。
- 利用者のデータを扱うかを確認し、扱うならOAuthを前提にする。
- APIキーの場合は、発行したらすぐに、APIの種類と使える場所の制限を設定する。
- キーを、ソースコードや共有の文書に書かず、安全な保管の仕組みに入れる。
- OAuthの場合は、必要最小限のスコープだけを要求する。
- 定期的にキーを入れ替え、使われていないキーを無効にする。
- 利用状況を確認し、不審なアクセスがないか見る。
APIキーとOAuthの違いの注意点
- キーやトークンは、パスワードと同じ扱いが必要です。チャットやメールで、そのまま送らないでください。
- 公開のリポジトリにキーをアップロードすると、短時間で悪用されることがあります。誤って公開したときは、すぐに無効にして、再発行します。
- 権限を広く与えるほど、漏えい時の被害が大きくなります。最小限にします。
- 認証方式の仕様や推奨は、更新されます。最新の公式ドキュメントを確認します。
- 連携ツールに認証情報を渡すときは、そのツールの安全性と、渡す権限の範囲を確認します。
APIキーとOAuthの違いでよくあるミス
- 制限を設定しないまま、キーを使う。
- キーを、画面側のコードや公開のリポジトリに入れる。
- 全権限のキーを、簡単な連携のために使う。
- 退職者が使っていたキーを、そのまま残す。
APIキーとOAuthの違いのチェックリスト
- 利用者のデータを扱うか確認し、方式を選んだか。
- キーに、APIと場所の制限をかけたか。
- キーを、安全な方法で保管しているか。
- スコープや権限が、必要最小限か。
- 入れ替えと、無効化の手順があるか。
APIキーとOAuthの違いのFAQ（よくある質問）
Q. APIキーだけで、安全に使えますか。
A. 公式ドキュメントでは、制限の設定と保護を前提としています。制限のないキーを公開することは避けてください。重要な処理には、より厳密な方式が推奨されています。
Q. OAuthは、難しいですか。
A. 仕組みの理解は必要ですが、連携ツールや公式のライブラリが、手順を代行してくれる場合が多いです。
Q. キーを漏らしてしまったら、どうすればよいですか。
A. すぐに無効にして再発行し、利用の履歴に不審な点がないか確認します。必要なら、提供元に連絡します。
筆者の見解（APIキーとOAuthの違い）
認証方式の選択では、使いやすさより、漏れたときの被害の大きさで考えるべきだと考えます。APIキーは手軽な反面、漏れると誰でも使えるため、制限と管理が前提になります。私見では、利用者のデータに触れる連携はOAuth、公開情報の取得はAPIキーと割り切り、どちらの場合も、キーをコードに書かない、権限を絞る、入れ替えるの3点を、最初から習慣にしておくのが、現実的だと思います。
APIキーとOAuthの違いの関連項目
出典（一次情報）
本記事は一般的な情報の提供を目的としています。SaaS・ツールの機能・料金・無料枠・仕様は頻繁に更新されるため、最新の内容は各社の公式ページでご確認ください。契約・法務・セキュリティに関する判断は、専門家や社内の担当部門にご相談ください。「筆者の見解」は一つの考え方です。