💭

APIの認証方式をまとめてみた

に公開
API
認証
idea

APIを設計・利用するときに必ず出てくるのが「認証」。
ここでは代表的な認証方式を整理してみました。

1. APIキー認証

サーバーが固定のキーを発行し、クライアントはそれをヘッダに付けて送信する方式です。

例:

Authorization: Api-Key xxxxx

特徴

  • 実装が単純で分かりやすい
  • 機械間通信や内部APIで使われやすい
  • 漏洩したら即悪用されるので取り扱い注意
  • 権限管理はシンプル

2. Basic認証

HTTPの標準仕様であるBasic認証を利用します。

例:

Authorization: Basic base64(username:password)

特徴

  • 実装が簡単
  • 今はテストや限定公開の簡易保護程度で利用されることが多い
  • セキュリティ的には弱い

3. Bearerトークン認証

ログインやトークン発行APIで得た「アクセストークン」を使います。

例:

Authorization: Bearer xxxxx

特徴

  • 今もっとも一般的な方式
  • トークンはただの乱数でもよい
  • 有効期限や権限を管理しやすい
  • トークン漏洩時のリスクは大きい

4. JWT（JSON Web Token）

Bearerトークンを「署名付きの自己完結トークン」にしたものです。

特徴

  • サーバーはDBを参照せず、署名検証だけでユーザーを特定可能
  • 有効期限やスコープなどの情報を埋め込める
  • 分散システムやモバイルアプリの認証に向いている
  • トークンが大きくなりがち、失効処理が難しい課題もある

5. OAuth 2.0 / OpenID Connect

外部サービス認証やサードパーティアプリ連携に使われます。

特徴

  • 「ユーザーがGoogleでログインして、そのアクセストークンでAPIを叩く」ようなケースで利用される
  • スコープで利用できる権限を細かく制御できる
  • フローが複数あり（Authorization Code, PKCE, Client Credentialsなど）、学習コストは高め
  • OpenID ConnectはOAuth 2.0に「IDトークン」を加え、本人確認まで含めた仕組み

まとめ

  • シンプルに使いたいなら APIキー
  • お手軽に保護したいなら Basic認証
  • 標準的な実装なら Bearerトークン
  • 本格的な認可や分散環境なら JWT
  • サードパーティや外部サービス連携なら OAuth 2.0 / OIDC

APIの認証方式は利用シーンや求めるセキュリティレベルによって使い分けが必要です。

Discussion