API セキュリティガイド｜OAuth 2.0・JWT・API Key の使い分けと実装方法

APIセキュリティが企業のリスクに直結する時代

マイクロサービスアーキテクチャの普及、SaaS間連携の増加、モバイルアプリのバックエンドAPI化――現代のシステムはAPIを中心に構築されている。OWASP（Open Worldwide Application Security Project）の報告によれば、Webアプリケーションへの攻撃の40%以上がAPI経由で行われており、APIセキュリティの重要性は年々高まっている。

APIの認証・認可を適切に設計しなければ、不正アクセス、データ漏洩、なりすまし攻撃といったリスクに直結する。しかし、OAuth 2.0、JWT、API Keyといった認証方式の使い分けを正確に理解しているエンジニアは意外と少ない。

本記事では、これら3つの認証・認可方式の仕組み、適切な使い分け、実装上の注意点を体系的に解説する。

---

認証と認可の違いを明確にする

APIセキュリティを理解するうえで、まず「認証（Authentication）」と「認可（Authorization）」の違いを明確にしておく必要がある。

認証（Authentication）: 「あなたは誰か」を確認するプロセス。ユーザーIDとパスワードによるログイン、多要素認証などが該当する。

認可（Authorization）: 「あなたに何が許可されているか」を判定するプロセス。認証されたユーザーが特定のリソースにアクセスできるかどうかを制御する。

OAuth 2.0は主に認可のフレームワークであり、JWTはトークンのフォーマット、API Keyは簡易的な認証手段だ。この位置づけを混同すると、設計上の誤りにつながる。

---

API Key: 最もシンプルな認証手段

仕組み

API Keyは、APIの利用者に発行される一意の文字列だ。リクエスト時にHTTPヘッダーやクエリパラメータに含めて送信する。

GET /api/data HTTP/1.1
Host: api.example.com
X-API-Key: sk_live_abc123def456

メリット

• 実装が最もシンプルで、導入障壁が低い
• サーバーサイドの実装負荷が小さい
• サービス間通信（Machine-to-Machine）に適している

デメリット

• API Key単体では「誰が」アクセスしているかを特定できない（認証ではなく識別に近い）
• キーの漏洩リスクが高い（ソースコードへのハードコード、ログへの記録等）
• アクセス権限の粒度が粗い（全権限か無権限かの二択になりやすい）
• キーのローテーション（定期的な更新）が運用上の負担になる

適切な用途

• 公開APIの利用量制限（レートリミット）の識別子として
• 内部サービス間のシンプルな認証として
• 開発・テスト環境でのプロトタイピングとして

実装上の注意点

1. API Keyは必ずHTTPSで送信する。HTTP通信では傍受される可能性がある
2. クエリパラメータではなくHTTPヘッダーで送信する（URLはログに記録されやすい）
3. サーバー側ではAPI Keyをハッシュ化して保存する（平文保存は厳禁）
4. キーのローテーション手順を事前に策定する
5. 環境変数やシークレットマネージャーで管理し、ソースコードにハードコードしない

---

OAuth 2.0: 認可の標準フレームワーク

仕組み（補足2）

OAuth 2.0は、リソースオーナー（ユーザー）がサードパーティアプリケーションに対して、自身のリソースへのアクセス権限を委譲するためのフレームワークだ。

例えば、「Webアプリケーションがユーザーに代わってGoogleカレンダーの予定を読み取る」というユースケースでは、ユーザーはGoogleの認可画面でアクセスを許可し、アプリケーションはアクセストークンを取得してAPIにアクセスする。

4つの認可フロー（Grant Type）

Authorization Code Flow: 最も標準的なフロー。認可サーバーがAuthorizationコードを発行し、サーバーサイドでアクセストークンに交換する。クライアントシークレットがブラウザに露出しないため安全性が高い。

Authorization Code Flow + PKCE: モバイルアプリやSPA（Single Page Application）向けの拡張。クライアントシークレットを安全に保管できないクライアントのために、コードチャレンジ/コードベリファイアの仕組みを追加する。

Client Credentials Flow: ユーザーが介在しないサービス間通信で使用する。クライアントID・クライアントシークレットでアクセストークンを取得する。

Device Code Flow: キーボード入力が困難なデバイスでの認可に使用する。

Implicit FlowとResource Owner Password Credentials Flowについて

かつて使用されていたImplicit FlowとResource Owner Password Credentials Flowは、セキュリティ上の問題からOAuth 2.1では正式に廃止された。新規のAPI設計でこれらのフローを採用してはならない。

実装上の注意点（補足2）

1. アクセストークンの有効期間は短く設定する（15分～1時間が目安）
2. リフレッシュトークンを併用して、ユーザー体験を損なわずにセキュリティを確保する
3. スコープ（権限範囲）を最小限に設定する（最小権限の原則）
4. トークンの失効（Revocation）エンドポイントを実装する
5. リダイレクトURIの完全一致検証を行う（オープンリダイレクト脆弱性の防止）

---

JWT（JSON Web Token）: トークンのフォーマット

仕組み（補足3）

JWTは、JSON形式のデータを安全に伝達するためのトークンフォーマットだ。OAuth 2.0のアクセストークンやIDトークン（OpenID Connect）として広く利用されている。

JWTは3つのパートから構成される。

• Header: 署名アルゴリズム（RS256、ES256等）とトークンタイプを記述
• Payload: ユーザーID、権限、有効期限などのクレーム（属性情報）を記述
• Signature: HeaderとPayloadの改ざんを検知するための署名

これら3つのパートがBase64URLエンコードされ、ドットで連結される。

eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.signature

JWTのメリット

• ステートレス: サーバー側でセッション情報を保持する必要がない。トークン自体に必要な情報が含まれるため、マイクロサービス間での認証に適している
• スケーラビリティ: セッションストアが不要なため、水平スケーリングが容易
• 標準化: RFC 7519として標準化されており、各言語のライブラリが充実している

JWTのデメリットと注意点

• トークンサイズ: Cookie等と比較してサイズが大きく、リクエスト毎のオーバーヘッドがある
• 失効の困難さ: 一度発行したJWTは有効期限まで無効化できない（ブラックリスト方式での対応が必要）
• ペイロードの可読性: Base64URLエンコードは暗号化ではなく、デコードすれば誰でも内容を読める。機密情報をペイロードに含めてはならない

署名アルゴリズムの選択

非対称鍵アルゴリズム（RS256、ES256）は、秘密鍵で署名し公開鍵で検証する方式だ。マイクロサービス間では公開鍵のみを配布すればよく、秘密鍵の管理範囲を限定できる。

HS256は共有鍵方式であり、検証側にも署名用の鍵を配布する必要がある。鍵の管理が煩雑になるため、複数サービス間での使用は推奨しない。

実装上の注意点（補足3）

1. 署名アルゴリズム「none」を許可しない（alg:none攻撃の防止）
2. ペイロードに機密情報を含めない（JWTはエンコードであって暗号化ではない）
3. 有効期限（exp）を必ず設定する
4. issuer（iss）とaudience（aud）の検証を実装する
5. JWTの保存場所に注意する（ブラウザではHttpOnly Cookieが推奨、localStorageはXSS攻撃のリスクがある）

---

3方式の使い分けガイド

---

OWASP API Security Top 10 への対応

2023年に更新されたOWASP API Security Top 10は、APIセキュリティの主要な脅威を体系化している。認証・認可に関連する項目を中心に対応策を示す。

API1: Broken Object Level Authorization

他のユーザーのリソースに不正アクセスできる脆弱性。APIのエンドポイントで、リクエスト元のユーザーがアクセス対象のリソースに対する権限を持っているかを必ず検証する。

API2: Broken Authentication

認証メカニズムの不備。ブルートフォース対策（レートリミット、アカウントロック）、トークンの適切な有効期限設定、多要素認証の導入が対策となる。

API3: Broken Object Property Level Authorization

オブジェクトのプロパティレベルでのアクセス制御の不備。レスポンスに含めるフィールドをホワイトリスト方式で制御し、不要な情報の露出を防ぐ。

---

APIゲートウェイによるセキュリティの一元管理

APIの数が増えてくると、各APIに認証・認可のロジックを個別に実装するのは非効率であり、実装漏れのリスクも高まる。APIゲートウェイを導入することで、セキュリティポリシーを一元管理できる。

主要なAPIゲートウェイの機能を以下に示す。

代表的なAPIゲートウェイとしては、Kong、AWS API Gateway、Azure API Management、Google Apigeeがある。

---

セキュリティテストの実施

APIセキュリティの設計・実装が完了したら、以下のテストを実施して脆弱性がないことを確認する。

1. 認証バイパステスト: トークンなしでAPIにアクセスし、適切に拒否されることを確認する
2. 権限昇格テスト: 一般ユーザーのトークンで管理者APIにアクセスし、拒否されることを確認する
3. トークン改ざんテスト: JWTのペイロードを改ざんしてリクエストし、署名検証で拒否されることを確認する
4. 期限切れトークンテスト: 有効期限切れのトークンでリクエストし、拒否されることを確認する
5. レートリミットテスト: 短時間に大量のリクエストを送信し、適切に制限されることを確認する

---

まとめ

APIセキュリティの設計は、認証方式の選定から始まる。API Key、OAuth 2.0、JWTはそれぞれ異なる目的と特性を持っており、ユースケースに応じた使い分けが必要だ。

実装にあたっては、OWASP API Security Top 10を参照しながら、認証バイパスや権限昇格といった典型的な脆弱性への対策を組み込む。APIゲートウェイの導入による一元管理も、セキュリティレベルの底上げと運用効率の改善に有効だ。

APIセキュリティ設計の無料相談

「OAuth 2.0の実装方針に不安がある」「API認証の設計レビューを受けたい」「既存APIのセキュリティ診断を依頼したい」――そのようなお悩みがありましたら、GXOにご相談ください。認証・認可の設計からセキュリティテストまで、御社のAPI基盤の安全性を確保するための支援をご提案します。 セキュリティ設計の相談をする ※ 営業電話はしません | オンライン対応可 | 相談だけでもOK

実務判断のポイント

この記事は、経営者、CIO、情シス、セキュリティ担当、開発責任者向けです。脆弱性管理、外部公開資産棚卸し、月次セキュリティ運用、インシデント対応を自社で進めるか、外部の専門家と整理するかを判断する材料として使えます。

GXOが重視するのは、話題性の高さよりも「自社の業務、データ、権限、予算、運用責任にどう影響するか」です。API セキュリティガイド｜OAuth 2.0・JWT・API Key の使い分けと実装方法に関する検討では、担当者だけで判断を閉じず、経営、現場、情シス、外部パートナーの役割を早い段階で分けることが重要です。

放置した場合と整備した場合の違い

導入・改善前のチェックリスト

• 対象業務、対象部門、対象データを明文化しているか
• 現在の課題を、売上機会、原価、工数、リスクのいずれかに分解しているか
• 既存システム、SaaS、Excel、手作業の依存関係を棚卸ししているか
• 例外処理、承認、差し戻し、監査証跡まで確認しているか
• 社内で判断できる範囲と外部支援が必要な範囲を分けているか
• 初期費用だけでなく、保守、運用、教育、改善費用を見積もっているか
• 成功指標を、問い合わせ数、商談数、削減時間、停止リスクなどで定義しているか
• 実装後の責任者、更新頻度、レビュー会議の持ち方を決めているか
• セキュリティ、法務、個人情報、契約条件の確認ポイントを洗い出しているか
• 既存の問い合わせ、商談、障害、運用ログから優先順位を決めているか
• 経営判断に必要な資料を1枚で説明できる状態にしているか
• 次の90日で検証する範囲と、やらない範囲を明確にしているか

GXOの見解

セキュリティニュースは読むだけでは価値がなく、自社資産、影響判定、対応期限、経営報告に変換して初めて防御力になる。

GXOは単発診断よりも、月次の棚卸し、優先順位付け、証跡管理、改善実行までを運用化すべきだと見る。

GXOは、脆弱性診断、インシデント対応、月次運用、開発保守の改善まで接続できる形で支援します。記事のテーマを単なる情報収集で終わらせず、相談、診断、要件定義、実装、運用改善に接続することで、診断、監査、保守契約、月次レポート、緊急対応支援へ接続。さらに、チェックリスト型診断を入口に、継続監視・改善支援へ展開。

実行までの進め方

1. 現在の業務、データ、ツール、担当者を棚卸しする
2. 売上拡大、工数削減、リスク低減のどれに効くテーマかを決める
3. 初期対応、90日以内の改善、半年以上の投資を分ける
4. 必要な社内体制、外部支援、予算、セキュリティ確認を整理する
5. 小さく検証し、効果測定後に本番化や横展開を判断する

FAQ

まず何から確認すべきですか？

最初に確認すべきなのは、対象業務、対象データ、責任者、判断期限です。情報収集だけで終えると、導入可否や対応優先順位を決められません。

社内だけで進めるべきですか？

既存業務の棚卸しは社内で進められます。ただし、要件定義、セキュリティ、費用対効果、ベンダー比較が絡む場合は、外部視点を入れた方が手戻りを抑えやすくなります。

GXOにはどの段階で相談できますか？

構想段階、予算化前、RFP作成前、既存システムの見直し段階から相談できます。脆弱性管理、外部公開資産棚卸し、月次セキュリティ運用、インシデント対応の相談を入口に、実装や運用改善まで整理できます。

参考情報

• 制度、価格、仕様、脆弱性、法務、セキュリティに関する判断は、公開時点の公式情報と一次情報を確認したうえで更新してください。