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ヘッダーやクエリパラメータに含めて送信する。

メリット

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

デメリット

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

適切な用途

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

実装上の注意点

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

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

仕組み

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

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

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

フロー	用途	セキュリティ
Authorization Code	Webアプリケーション	高い
Authorization Code + PKCE	モバイル・SPA	高い
Client Credentials	サービス間通信	中程度
Device Code	TVやIoTデバイス	中程度

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設計でこれらのフローを採用してはならない。

実装上の注意点

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

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

仕組み

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

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

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

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

JWTのメリット

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

JWTのデメリットと注意点

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

署名アルゴリズムの選択

アルゴリズム	種別	推奨度	用途
RS256	RSA非対称鍵	推奨	一般的なAPI認証
ES256	ECDSA非対称鍵	推奨	パフォーマンス重視
HS256	HMAC共有鍵	条件付き	単一サービス内のみ
none	署名なし	使用禁止	--

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

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

実装上の注意点

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

3方式の使い分けガイド

ユースケース	推奨方式	理由
SaaSのパブリックAPI	OAuth 2.0 + JWT	ユーザー認可とスコープ制御が必要
モバイルアプリのバックエンドAPI	OAuth 2.0 (PKCE) + JWT	セキュアな認可フローが必要
内部マイクロサービス間通信	JWT（Client Credentials）	ステートレスな認証が効率的
外部パートナーAPI連携	OAuth 2.0 or API Key	パートナーの技術力に応じて判断
Webhookの受信	API Key + 署名検証	シンプルかつ改ざん検知が可能
開発・テスト環境	API Key	迅速な開発が優先

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ゲートウェイの機能を以下に示す。

機能	内容
認証・認可	OAuth 2.0 / JWT検証を一元的に処理
レートリミット	API Keyやユーザー単位での呼び出し回数制限
IPフィルタリング	許可リスト・拒否リストによるアクセス制御
リクエスト検証	リクエストボディのスキーマ検証
ログ・監査	全APIリクエストの記録と監査ログの生成
TLS終端	HTTPS通信の終端処理

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

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

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

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

まとめ

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

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

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

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

セキュリティ設計の相談をする

※ 営業電話はしません | オンライン対応可 | 相談だけでもOK