REST APIの認証方式まとめ｜APIキー・JWT・OAuth・Cookie認証

この記事の最終更新日: 2026年5月27日

REST APIを作るときに避けて通れないのが 認証 です。

APIは、単にデータを取得・登録・更新・削除できればよいわけではありません。

「誰がそのAPIを使っているのか」
「その人はその操作をしてよいのか」
「外部サービスにどこまでアクセスを許可するのか」

といったことを安全に判断する必要があります。

REST APIの認証方式として、よく出てくるのが次の4つです。

この記事では、REST APIでよく使われる APIキー・JWT・OAuth・Cookie認証 の違いと使い分けを、初心者にもわかりやすく解説します。

まず「認証」と「認可」の違いを理解する

API認証を理解する前に、まず 認証 と 認可 の違いを押さえておきましょう。

たとえば、ログイン処理は認証です。

POST /login

{
  "email": "yamada@example.com",
  "password": "password123"
}

メールアドレスとパスワードを確認して、「この人は山田さんです」と判断します。

一方で、認可は「山田さんがこの操作をしてよいか」を確認することです。

たとえば、一般ユーザーが管理者専用APIを呼び出した場合は、ログイン済みでも拒否する必要があります。

DELETE /admin/users/1

この場合、ログインしているかどうかだけでなく、管理者権限があるかを確認します。

API認証では、認証と認可をセットで考えることが大切です。

REST APIで認証が必要になる理由

REST APIでは、クライアントがサーバーにリクエストを送ります。

クライアント
    ↓ リクエスト
REST API
    ↓
サーバー

認証がないAPIでは、サーバーは「誰からのリクエストなのか」を判断できません。

たとえば、次のようなAPIがあったとします。

GET /me

このAPIは「自分のユーザー情報を取得する」APIです。

しかし、認証情報がなければ、サーバーは「自分」が誰なのかわかりません。

そのため、ログイン後のAPIでは、リクエストに認証情報を付けて送ります。

GET /me
Authorization: Bearer xxxxxxxx

または、Cookieを使う場合は、ブラウザがCookieを自動的に送信します。

GET /me
Cookie: session_id=xxxxxxxx

このように、API認証は「誰からのリクエストか」をサーバーが判断するために必要です。

API認証方式の全体像

REST APIでよく使われる認証方式をざっくり整理すると、次のようになります。

どれが一番良いという話ではありません。

それぞれ得意な場面が違います。

APIキー認証とは

APIキー認証とは、APIを利用するための キー文字列 を発行し、そのキーをリクエストに付けて送る方式です。

たとえば、外部APIを使うときによく見かけます。

GET /weather
X-API-Key: abc123xxxxxxxx

または、クエリパラメータで送る形式もあります。

GET /weather?api_key=abc123xxxxxxxx

ただし、クエリパラメータにAPIキーを入れると、アクセスログやブラウザ履歴などに残りやすいため、基本的にはヘッダーで送る方が望ましいです。

APIキー認証のイメージ

APIキー認証は、シンプルに言うと「合鍵」のようなものです。

クライアント：このAPIキーを持っています
サーバー：そのキーは有効ですね。API利用を許可します

APIキーが正しければ、APIの利用を許可します。

そのため、実装は比較的シンプルです。

APIキー認証のメリット

APIキー認証のメリットは、わかりやすく実装しやすいことです。

特に、次のようなケースで使いやすいです。

• 外部APIを利用する
• サーバー間で通信する
• 社内システム同士を接続する
• 利用者ごとにAPI利用量を管理する
• APIごとにアクセス制限をしたい

たとえば、外部の天気APIや決済API、地図APIを使うときにAPIキーが発行されることがあります。

APIキー認証のデメリット

APIキー認証には、注意点もあります。

一番大きいのは、漏えいした場合に悪用されやすい ことです。

APIキーは固定の文字列なので、第三者に知られると、そのキーを使ってAPIを呼び出される可能性があります。

そのため、次のような対策が重要です。

• APIキーをフロントエンドに直接埋め込まない
• GitHubなどにコミットしない
• 定期的にローテーションする
• 利用可能なIPアドレスを制限する
• 利用できるAPIや権限を絞る
• 利用量制限を設ける
• HTTPSで通信する

OWASPのREST Security Cheat Sheetでも、RESTサービスはHTTPSのみで提供すべきであり、APIキーやJWTなどの認証情報を通信中に保護する必要があるとされています。(OWASP Cheat Sheet Series)

APIキー認証が向いているケース

APIキー認証は、主に 人間のログイン よりも システム間連携 に向いています。

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

自社サーバー → 外部API
バッチ処理 → 社内API
管理システム → 別システムのAPI

一方で、ユーザーごとのログイン状態を細かく管理する用途にはあまり向いていません。

「山田さんがログインしている」「佐藤さんがログインしている」といったユーザー単位の認証には、JWTやCookie認証の方が向いています。

JWT認証とは

JWT認証とは、JSON Web Token を使った認証方式です。

JWTは、ユーザーIDや有効期限などの情報を含められるトークン形式です。

RFC 7519では、JWTは2者間でクレーム、つまり情報の主張をやり取りするためのコンパクトでURLセーフな形式として定義されています。(IETF Datatracker)

ログインに成功すると、サーバーはJWTを発行します。

POST /login

{
  "email": "yamada@example.com",
  "password": "password123"
}

レスポンス例です。

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6...",
  "token_type": "Bearer",
  "expires_in": 3600
}

クライアントは、その後のAPIリクエストでJWTを送ります。

GET /me
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6...

JWTの中身

JWTは、基本的に次の3つの部分で構成されます。

ヘッダー.ペイロード.署名

たとえば、次のようなイメージです。

xxxxx.yyyyy.zzzzz

JWTのペイロードには、次のような情報を含めることがあります。

{
  "sub": "1",
  "name": "山田太郎",
  "role": "user",
  "exp": 1760000000
}

ただし、JWTのペイロードは暗号化されていない場合、誰でも中身を読めます。

そのため、パスワードや個人情報のような機密情報をJWTに入れてはいけません。

JWT認証のメリット

JWT認証のメリットは、API認証と相性が良いことです。

特に、次のようなケースで使われます。

• SPA
• スマホアプリ
• フロントエンドとバックエンドが分離した構成
• 複数のAPIサーバーがある構成
• Authorizationヘッダーで認証したい場合

JWTは署名を検証することで、トークンが改ざんされていないか確認できます。

また、セッションID方式と違って、トークンの中にユーザーIDや有効期限などを含められるため、APIサーバー側で毎回セッションストアを参照しない設計にもできます。

JWT認証のデメリット

JWTには注意点もあります。

特に重要なのは、一度発行したトークンを失効しづらい ことです。

通常のセッションIDであれば、サーバー側のセッションを削除すればログアウトできます。

しかし、JWTはトークン自体が有効期限を持つため、有効期限が切れるまでは使えてしまう設計になりがちです。

そのため、JWTでは次のような対策を考えます。

• アクセストークンの有効期限を短くする
• リフレッシュトークンを使う
• トークンの失効リストを管理する
• 重要な操作では再認証する
• 秘密鍵を安全に管理する
• exp などのクレームを正しく検証する

RFC 7519でも、exp はその時刻以降JWTを処理してはならないことを示すクレームとして定義されています。(IETF Datatracker)

JWTをどこに保存するか問題

JWT認証でよく議論になるのが、クライアント側でJWTをどこに保存するかです。

主な選択肢は次の通りです。

localStorage に保存すると実装は簡単ですが、XSSがあるとJavaScriptから盗まれる可能性があります。

一方、HttpOnly Cookieに保存するとJavaScriptからは読めませんが、Cookieはブラウザが自動送信するためCSRF対策が必要になります。

つまり、「JWTだから安全」ではなく、保存方法と攻撃リスクまで含めて考える必要があります。

OAuthとは

OAuthは、主に 外部サービスへの権限委譲 に使われる仕組みです。

OAuth 2.0は、第三者アプリケーションがHTTPサービスに対して限定的なアクセスを得るための認可フレームワークとして定義されています。(IETF Datatracker)

たとえば、次のような場面で使われます。

自分のアプリからGoogleカレンダーに予定を登録する
自分のアプリからGitHubのリポジトリ情報を取得する
外部サービスのアカウントでログインする

OAuthのポイントは、ユーザーが自分のパスワードを第三者アプリに渡さなくても、限定的なアクセス権を付与できることです。

OAuthは「ログイン方式」ではなく「認可」の仕組み

ここはとても誤解されやすいです。

よく「OAuthログイン」という言葉を聞きますが、OAuth自体は本来、認証ではなく 認可 の仕組みです。

つまり、OAuthの中心は次の考え方です。

このアプリに、私のGoogleカレンダーの読み取りだけを許可します
このアプリに、GitHubのリポジトリ一覧の取得だけを許可します
このアプリに、投稿権限だけを許可します

ユーザーの本人確認、つまりログイン用途では、OAuthの上にOpenID Connectを使うことが多いです。

ただし、初心者向けにはまず次の理解で十分です。

OAuthは、外部サービスのデータや機能に対して、限定的なアクセス権を渡す仕組み。

OAuthの基本的な流れ

OAuthの流れをざっくり書くと、次のようになります。

1. ユーザーが「Googleと連携する」ボタンを押す
2. Googleの認可画面に移動する
3. ユーザーがアクセス許可を承認する
4. アプリが認可コードを受け取る
5. アプリが認可コードをアクセストークンに交換する
6. アプリがアクセストークンを使ってGoogle APIを呼び出す

OAuthでは、ユーザーが外部サービスのパスワードをアプリに直接渡す必要がありません。

代わりに、アクセストークンを使って許可された範囲だけAPIを利用します。

OAuthが向いているケース

OAuthは、次のようなケースに向いています。

• Googleアカウントでログインする
• GitHub連携をする
• XやSlackなどのAPIを利用する
• 外部サービスのデータにアクセスする
• ユーザーに代わって外部APIを操作する
• 第三者アプリに限定的な権限を渡す

特に、外部サービスとの連携ではOAuthがよく使われます。

OAuthの注意点

OAuthは便利ですが、JWTやAPIキーよりも仕組みが複雑です。

設計時には次の点に注意が必要です。

• リダイレクトURIの検証
• スコープの設計
• アクセストークンの管理
• リフレッシュトークンの管理
• PKCEの利用
• stateパラメータによるCSRF対策
• クライアントシークレットの管理
• OpenID Connectとの違い

また、OAuth 2.1は2026年5月時点ではIETFのドラフトとして扱われており、OAuth 2.0やBearer Token Usageを置き換える内容として作業が進められています。(IETF Datatracker)

新規実装ではOAuth 2.0の基本だけでなく、現在推奨されるセキュリティプラクティスも確認するのが安全です。

Cookie認証とは

Cookie認証とは、ログイン後にサーバーがCookieを発行し、ブラウザがそのCookieを自動的に送ることで認証する方式です。

MDNによると、Set-Cookie ヘッダーはサーバーからユーザーエージェントにCookieを送信し、その後ユーザーエージェントがサーバーへCookieを返送できるようにするために使われます。(MDNウェブドキュメント)

ログイン時の流れは次のようになります。

POST /login

{
  "email": "yamada@example.com",
  "password": "password123"
}

サーバーはログイン成功時にCookieを返します。

Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax

その後、ブラウザは同じサイトへのリクエストでCookieを自動的に送ります。

GET /me
Cookie: session_id=abc123

Cookie認証のイメージ

Cookie認証は、昔からWebアプリでよく使われている方式です。

1. ログインする
2. サーバーがセッションIDをCookieに入れて返す
3. ブラウザが次回以降のリクエストでCookieを自動送信する
4. サーバーがCookieのセッションIDを見てユーザーを判定する

LaravelやRailsなどのWebフレームワークでは、従来からこの方式がよく使われます。

Cookie認証のメリット

Cookie認証は、ブラウザ向けWebアプリと相性が良いです。

メリットは次の通りです。

• ブラウザがCookieを自動送信してくれる
• サーバー側でセッションを管理しやすい
• ログアウトや強制失効がしやすい
• HttpOnly属性でJavaScriptからCookieを読めなくできる
• SSRや通常のWebアプリと相性が良い

MDNは、HttpOnly 属性付きCookieはJavaScriptの Document.cookie からアクセスできないため、クロスサイトスクリプティング攻撃を軽減する助けになると説明しています。(MDNウェブドキュメント)

Cookie認証のデメリット

Cookie認証にも注意点があります。

特に重要なのは、CSRF対策 です。

Cookieはブラウザが自動的に送信するため、悪意あるサイトからユーザーのブラウザを経由してリクエストを送られるリスクがあります。

そのため、Cookie認証では次のような対策が重要です。

• CSRFトークンを使う
• SameSite属性を設定する
• Secure属性を設定する
• HttpOnly属性を設定する
• CORS設定を適切にする
• セッション固定攻撃への対策をする

MDNでは、Secure 属性付きCookieはHTTPS上のリクエストでのみ送信され、HttpOnly 属性付きCookieはJavaScriptからアクセスできないと説明されています。(MDNウェブドキュメント)

Cookie認証が向いているケース

Cookie認証は、次のようなケースに向いています。

• ブラウザ向けWebアプリ
• サーバーサイドレンダリング
• LaravelやRailsなどの通常のWebアプリ
• 管理画面
• 同一ドメイン内のフロントエンドとバックエンド
• セッション管理をサーバー側で行いたい場合

逆に、スマホアプリや外部API連携では、Cookie認証よりもBearer TokenやOAuthの方が扱いやすいことが多いです。

APIキー・JWT・OAuth・Cookie認証の比較

4つの方式を比較すると、次のようになります。

どの認証方式を選ぶべきか

実務では、次のように考えると選びやすいです。

サーバー間連携ならAPIキー

たとえば、バッチ処理や社内システム同士の通信ならAPIキーが使いやすいです。

GET /internal/reports
X-API-Key: xxxxxxxx

ただし、IP制限や権限制限、利用量制限を組み合わせると安全性が上がります。

SPAやスマホアプリならJWT

ReactやVueのSPA、またはスマホアプリからAPIを呼ぶなら、JWTやBearer Token方式がよく使われます。

GET /me
Authorization: Bearer xxxxxxxx

ただし、トークンの保存場所、有効期限、リフレッシュトークン、ログアウト時の扱いをきちんと設計する必要があります。

外部サービス連携ならOAuth

Google、GitHub、Slackなどと連携するならOAuthが候補になります。

ユーザーが外部サービスで許可
↓
アプリがアクセストークンを取得
↓
アクセストークンで外部APIを呼び出す

ユーザーのパスワードを預からずに、限定された権限だけを取得できるのがポイントです。

通常のWebアプリならCookie認証

LaravelやRailsなどで作る通常のWebアプリや管理画面なら、Cookie認証は今でも有力です。

Set-Cookie: session_id=xxxxx; HttpOnly; Secure; SameSite=Lax

特に、フロントエンドとバックエンドが同一ドメインで動く構成では扱いやすいです。

認証方式を選ぶときの判断基準

認証方式を選ぶときは、次の観点で考えるとよいです。

認証方式は「流行っているからJWT」「外部連携だから何でもOAuth」のように決めるべきではありません。

どのクライアントが、誰の権限で、どのAPIを呼ぶのかを考えて選ぶことが大切です。

よくある誤解

誤解1：JWTを使えばセッション管理は不要

JWTはサーバー側のセッションストアを不要にできる場合があります。

しかし、ログアウト、強制失効、権限変更の即時反映などを考えると、完全に状態管理が不要とは限りません。

たとえば、退職したユーザーのトークンを即座に無効化したい場合、有効期限が切れるまで待つだけでは不十分なことがあります。

その場合は、失効リストや短い有効期限、再認証などの仕組みが必要です。

誤解2：OAuthはログイン機能そのもの

OAuthは本来、認可の仕組みです。

「Googleでログイン」のようなログイン機能では、OAuthだけでなくOpenID Connectが使われることが多いです。

初心者のうちは、まず次のように区別するとよいです。

誤解3：Cookie認証は古い

Cookie認証は古い方式というより、ブラウザ向けWebアプリでは今でも普通に使われる方式です。

特に、サーバーサイドレンダリングや同一ドメイン構成のWebアプリでは、Cookie認証は扱いやすいです。

ただし、CSRF対策やCookie属性の設定を正しく行う必要があります。

誤解4：APIキーだけでユーザー認証をしてよい

APIキーは、システムやアプリケーションの識別には向いています。

しかし、個別のユーザー認証には向いていないことが多いです。

たとえば、1つのAPIキーを複数ユーザーで共有すると、「誰が操作したのか」がわかりにくくなります。

ユーザー単位の認証が必要なら、JWTやCookie認証などを検討した方が自然です。

誤解5：HTTPSなら認証情報を雑に扱ってよい

HTTPSは必須ですが、それだけで十分ではありません。

認証情報は漏えいした場合に大きな被害につながるため、次のような対策も必要です。

• トークンをログに出さない
• APIキーをソースコードに直書きしない
• CookieにSecureやHttpOnlyを付ける
• トークンに適切な有効期限を設定する
• 権限を最小限にする
• 不審なアクセスを監視する

HTTPSは前提であり、認証設計そのものを安全にする必要があります。

実務でよくある構成例

構成1：Laravelの管理画面

Laravelで管理画面を作る場合、Cookie認証がよく使われます。

ブラウザ
  ↓ Cookie
Laravel
  ↓
DB

この構成では、Laravelのセッション管理やCSRF対策を活用できます。

構成2：React SPA + Laravel API

ReactなどのSPAとLaravel APIを分離する場合、次の2パターンがあります。

パターンA: Cookie認証
React SPA
  ↓ Cookie
Laravel API

パターンB: JWT認証
React SPA
  ↓ Authorization: Bearer token
Laravel API

同一ドメインやサブドメイン構成ならCookie認証も選択肢になります。

一方、スマホアプリや複数クライアントから使うAPIならJWTの方が扱いやすい場合があります。

構成3：スマホアプリ + API

スマホアプリでは、Bearer Token方式がよく使われます。

GET /me
Authorization: Bearer xxxxxxxx

アクセストークンとリフレッシュトークンを使い、有効期限を管理します。

構成4：外部サービス連携

GoogleカレンダーやGitHub APIなどと連携する場合は、OAuthを使います。

ユーザーが外部サービスで許可
↓
アクセストークン取得
↓
外部API呼び出し

この場合、自分のアプリがユーザーのパスワードを預かる必要はありません。

構成5：サーバー間バッチ処理

夜間バッチや社内システム連携では、APIキーが使われることがあります。

POST /internal/import
X-API-Key: xxxxxxxx

ただし、IP制限や実行権限の制限を組み合わせる方が安全です。

初心者向けの選び方まとめ

初心者向けにかなり単純化すると、次のように考えるとわかりやすいです。

ただし、これはあくまで目安です。

実務では、セキュリティ要件や運用方針によって変わります。

API認証の実装で最低限気をつけたいこと

どの方式を選んでも、最低限次の点には注意しましょう。

1. HTTPSを使う

認証情報を扱うAPIでは、HTTPSは必須です。

HTTPのままAPIキーやトークンを送ると、通信経路で盗まれるリスクがあります。

2. 認証情報をログに出さない

APIキー、JWT、Cookie、アクセストークンなどをログにそのまま出すのは危険です。

特に、次の情報はマスクするべきです。

Authorization
Cookie
X-API-Key
access_token
refresh_token

3. 有効期限を設定する

トークンやAPIキーには、できるだけ有効期限やローテーションの仕組みを設けましょう。

特にJWTのアクセストークンは短めに設定し、必要に応じてリフレッシュトークンを使います。

4. 権限を最小限にする

すべての操作ができる強力なキーやトークンを発行すると、漏えい時の被害が大きくなります。

必要な操作だけを許可する設計にしましょう。

OAuthであれば、スコープを適切に分けます。

5. 401と403を使い分ける

認証エラーと権限エラーは分けて考えます。

401 Unauthorized

これは「ログインしていない、または認証情報が無効」という意味です。

403 Forbidden

これは「ログイン済みだが、その操作をする権限がない」という意味です。

この違いを意識すると、フロントエンド側のエラー表示や調査がしやすくなります。

まとめ

REST APIの認証方式には、さまざまな種類があります。

代表的なものは、APIキー、JWT、OAuth、Cookie認証です。

選び方の目安は次の通りです。

サーバー間通信ならAPIキー
SPAやスマホアプリならJWT
外部サービス連携ならOAuth
通常のWebアプリならCookie認証

ただし、認証方式に絶対的な正解はありません。

大切なのは、次の観点で選ぶことです。

誰がAPIを使うのか
どのクライアントから使うのか
認証情報をどこに保存するのか
失効やログアウトをどう扱うのか
外部サービス連携が必要か
XSSやCSRFへの対策が必要か
権限をどこまで細かく分けるのか

API認証は、REST APIの中でも特にセキュリティに直結する重要な領域です。

「JWTが流行っているからJWT」
「昔から使っているからCookie」
「簡単だからAPIキー」

と決めるのではなく、用途・クライアント・リスク・運用まで含めて選ぶようにしましょう。

daigoro

大阪のエンジニアが書いているブログ。