APIキーとは？OAuthと何が違うのか

最初に: APIキー と OAuth 2.0 は同じではない

API連携の話をしていると、APIキーで呼べますか？ OAuthが必要ですか？ という会話がよく出てきます。
ただ、この2つは役割がかなり違います。

ざっくり先に言うと、

• APIキー は どのアプリやプロジェクトから来た呼び出しか を識別するのに向いている
• OAuth 2.0 は どのユーザーの、どこまでの権限を使うか を委任する仕組み

です。

この違いが曖昧なままだと、

• APIキーでできると思っていたのに、途中でユーザーログインが必要になる
• 逆に OAuth を入れたが、本当はAPIキーだけで十分だった
• 認証情報の持ち方が雑で、漏えい時の被害が大きくなる

といった手戻りが起きやすくなります。

そこでこの記事では、APIキーとは何か、OAuth と何が違うのか、どんな場面で使い分けるのかを初心者向けに整理します。

この記事は 2026年4月24日時点の公開情報をもとに整理しています。APIキーの性質は Google Cloud の API key 関連ドキュメント、OAuth の役割は IETF の RFC 6749 を主な一次情報として参照しています。

APIキーとは何か

APIキー は、API を呼び出すアプリケーションやプロジェクトを識別するための文字列です。
Google Cloud のドキュメントでも、APIキーは呼び出し元プロジェクトを識別し、クォータ、課金、監視に関連づけるためのものと説明されています。

ここで大事なのは、APIキーが ユーザー本人 を表すものではないことです。

つまり APIキーは、

• このアプリから来た
• このプロジェクトにひもづく
• このキーに設定した制限範囲で呼べる

という整理には向いていますが、

• 今ログインしているユーザーは誰か
• そのユーザーがこのデータを見ていいか
• ユーザー本人の代理で投稿や更新をしてよいか

までは表現しにくいです。

OAuthとは何か

OAuth 2.0 は、IETF の RFC 6749 で定義されている認可フレームワークです。
仕様では、第三者アプリケーションが、リソース所有者の承認を得て、限定的なアクセスを取得する仕組みとして説明されています。

重要なのは、OAuth が本質的に 委任 の仕組みだということです。

たとえば、

• ユーザーのGoogle Driveにあるデータを読む
• ユーザーのSNSアカウントで投稿する
• ユーザーのカレンダー情報を取得する

のように、そのユーザーの権限を借りて操作する ときに使われます。

RFC 6749 でも、OAuth はユーザーのID/パスワードを第三者アプリへ直接渡さずに、スコープや有効期限つきのアクセストークンで限定的にアクセスさせる考え方として整理されています。

APIキーとOAuthの違い

違いを短くまとめると、次の表になります。

この表で見ると、APIキーは 誰の代わりに何をするか を扱う仕組みではない、という点がはっきりします。

どんなときにAPIキーで足りるのか

APIキーで足りるのは、主に 公開情報へのアクセス や アプリ単位の呼び出し識別 で十分な場面です。

たとえば次のようなケースです。

• 公開天気データを取得する
• 公開地図APIを呼ぶ
• サーバーから外部APIへ単純な問い合わせをする
• クォータや課金のひもづけがしたい

Google Cloud のドキュメントでも、標準APIキーはリクエストをプロジェクトへ関連づけるためのもので、主体を識別しないと説明されています。
つまり、この呼び出しはどのアプリから来たか には向いていますが、このユーザーが読んでいいか には向いていません。

どんなときにOAuthが必要なのか

OAuth が必要になるのは、ユーザー本人の権限 が関わるときです。

たとえば次のようなケースです。

• ユーザーのGoogleアカウントにひもづくデータを読む
• ユーザーのXアカウントで投稿する
• 個人のカレンダーやメールへアクセスする
• ユーザーごとに見えるデータ範囲が違う

このときは、単にアプリが誰か分かるだけでは足りません。
ユーザーがどこまで許可したか を表す必要があります。

OAuth ではそのために、スコープ、有効期限、アクセストークン、場合によってはリフレッシュトークンが出てきます。
この構造のおかげで、ユーザーのパスワードそのものを第三者アプリへ渡さずに済みます。

よくある使い分けの例

1. 公開データを見るだけ

この場合は APIキーで足りることが多いです。

たとえば、

• 公開YouTube動画情報
• 一般公開されている地図情報
• 公開されている検索系API

のように、個人の非公開データに触れないなら、OAuth を入れずに進められることがあります。

2. ユーザー本人のデータを読む

この場合は OAuth が必要です。

たとえば、

• 自分のチャンネル情報を取得する
• 非公開の分析データを見る
• ユーザー専用のリソースへアクセスする

のようなケースです。

3. ユーザー本人として書き込む

これも OAuth が必要です。

• 投稿する
• 削除する
• フォローする
• 予定を追加する

のような操作は、本人の権限で動く必要があります。APIキーだけでは扱いにくいです。

4. サーバー間で固定用途の連携をする

これはケース次第ですが、APIキーやサービスアカウント系の仕組みで足りることがあります。
ユーザー単位ではなく、システム対システムで限定用途の通信なら、OAuth のユーザー委任フローは重すぎることがあります。

APIキーの危険なところ

APIキーはシンプルで扱いやすい反面、運用が雑になりやすいです。

1. ただの文字列なので漏えいしやすい

.env ではなくソースコードへ直書きしたり、フロントエンドへ露出したり、ログへ出したりすると、そのまま悪用される可能性があります。

2. 権限が広すぎると被害が大きい

APIキー自体に細かいユーザー委任がない分、制限を雑にすると そのキーでできること全部 が漏えい時の被害になります。

3. 使い回ししやすい

開発用、本番用、検証用で同じキーを使うと、事故時の切り分けもローテーションも難しくなります。

APIキーを使うなら最低限やること

Google Cloud のドキュメントでも、APIキーにはアプリケーション制限や API 制限を追加する考え方が案内されています。
実務でも次の対応は最低限やりたいです。

• APIごとに利用先を制限する
• ドメイン、IP、アプリなど発行先制限をかける
• 環境ごとにキーを分ける
• 不要になったキーを失効する
• リポジトリへ入れない
• ログや画面へ露出させない

つまり、APIキーは 簡単だから雑に使ってよい ではなく、簡単だからこそ制限を丁寧に付ける のが大事です。

OAuthのほうが常に優れているわけではない

ここも誤解されやすいです。

OAuth は強力ですが、導入コストがあります。

• ログイン導線が必要
• コールバックURL管理が必要
• アクセストークン管理が必要
• リフレッシュや失効の考慮が必要

なので、公開データ取得だけの小さな用途にまで毎回 OAuth を持ち込むと、構成が重くなりがちです。

大事なのは、誰の権限が必要か を先に決めることです。

• アプリ単位で十分なら APIキー
• ユーザー本人の権限が必要なら OAuth

この順で考えると迷いにくくなります。

よくある誤解

1. APIキーは安全なログイン方式

そうではありません。
APIキーは、一般にユーザーログインの代わりとして使うものではありません。

2. OAuthは認証そのもの

厳密には OAuth 2.0 は認可フレームワークです。
ログイン用途では、上に認証レイヤーを載せた OpenID Connect と一緒に出てくることが多いです。

3. APIキーで全部できるならそれが最強

一見簡単ですが、ユーザー単位の権限管理や委任が必要になると破綻しやすいです。
要件に合わない場面で無理にAPIキーだけで通そうとすると、設計が苦しくなります。

最初に押さえるべきか

最初は次の4つを押さえれば十分です。

1. APIキーはアプリやプロジェクトの識別向き
2. OAuthはユーザー権限の委任向き
3. 公開データならAPIキーで足りることがある
4. ユーザー本人のデータ取得や更新ならOAuthが必要になりやすい

この4つが分かると、API設計や外部連携での手戻りがかなり減ります。

まとめ

APIキー は、API を呼ぶアプリやプロジェクトを識別するための仕組みで、OAuth 2.0 は、ユーザー本人の権限を限定的に委任するための仕組みです。
似て見えても役割はかなり違います。

最初は次の理解で十分です。

• APIキー = アプリ識別
• OAuth = ユーザー権限の委任
• 公開データ取得なら APIキーで足りることがある
• 本人データや書き込み操作なら OAuth が必要になりやすい

この違いを先に整理しておくと、外部API連携の設計がかなり楽になります。

この記事と一緒に読みたい

1. Webhookとは？APIとの違い・よくある使い方・実務の注意点を解説
2. APIのレート制限とは？ログイン・Webhook・外部APIで必要になる理由
3. OpenAPI / Swaggerとは？API仕様書をチームで共有する基本を整理
4. SSOとは？仕組み・メリット・運用とセキュリティの注意点をわかりやすく解説
5. OpenID Connect

参考リンク

• Google Cloud Docs: Manage API keys
• Google Cloud Docs: Using API Keys
• Google Cloud Docs: Why and when to use API keys
• IETF: RFC 6749 The OAuth 2.0 Authorization Framework