API設計

API認証えーぴーあいにんしょう

APIキーOAuthJWTBearer トークン認可アクセス制御

API認証について教えて

簡単に言うとこんな感じ！

APIへのアクセスに「合言葉」や「身分証」を要求する仕組みだよ！「このシステムはちゃんと許可された相手か？」を確認するドアの鍵みたいなもので、無断アクセスや不正利用を防いでくれるんだ。

API認証とは

API認証（API Authentication）とは、APIを呼び出す側（クライアント）が「本当に許可された相手かどうか」をAPIサーバー側が確認するプロセスのことです。Webサービスやシステム連携でAPIを使う際、誰でも自由にアクセスできてしまうと、情報漏洩や不正操作・過剰利用（コスト増大）などのリスクが生じます。そこでAPIサーバーは「合言葉」や「身分証」にあたる情報をリクエストに要求し、正しい相手だけを通すようにします。

認証（Authentication）と似た言葉に認可（Authorization）があります。「認証」は「あなたは誰か？」を確認すること、「認可」は「あなたに何が許されているか？」を決めることです。API認証はこの両方をセットで扱うことが多く、たとえばOAuthでは認証後に「読み取りだけ許可」「書き込みも許可」といったスコープ（権限の範囲）を細かく制御できます。

実務上は、社内の基幹システムと外部SaaSを連携させるときや、自社が開発したアプリから外部APIを呼ぶときに必ず登場します。「どの認証方式を選ぶか」はセキュリティ・開発コスト・運用のしやすさに直結するため、システム発注時の要件定義でも重要な検討ポイントになります。

API認証の主な方式

方式	一言で言うと	使いどころ	セキュリティ強度
APIキー	固定の「合言葉」文字列	社内ツール連携・簡易API	低〜中
Basic認証	IDとパスワードをそのまま送る	レガシーシステム・テスト用	低（HTTPS必須）
Bearer トークン	一時的な「入場券」を使い回す	モバイルアプリ・SPA	中〜高
OAuth 2.0	権限を細かく委譲する仕組み	SNSログイン・SaaS連携	高
JWT	署名付きの「自己完結した身分証」	マイクロサービス・API間連携	高
相互TLS（mTLS）	サーバーとクライアント双方が証明書を提示	金融・医療など高セキュリティ領域	非常に高

覚え方：「鍵・票・証」で整理しよう

APIキー → 「合言葉の鍵」。固定なので漏れたら終わり。
トークン（Bearer/JWT） → 「有効期限付きの入場票」。期限切れで自動無効化できる。
mTLS → 「両者が本物かを確かめ合う身分証」。最も厳格。

JWT（JSON Web Token）の構造

JWTは3つのパーツをドット（.）でつないだ文字列です。

ヘッダー.ペイロード.署名
eyJhbGci...  .eyJzdWIi...  .SflKxwRJSMeKKF...
  ↑アルゴリズム情報   ↑ユーザー情報・有効期限   ↑改ざん検知用の署名

サーバーは署名を検証するだけで「本物か・期限切れでないか」がわかるため、データベースを毎回引かずに済む（ステートレス）のが強みです。

歴史と背景

1990年代末〜2000年代初頭 — Webサービス間連携にSOAPが使われ始める。認証はWS-Securityという複雑な仕様で行われた。
2000年 — Roy FieldingがREST（アーキテクチャスタイル）を提唱。シンプルなAPIの概念が広まる。
2007年頃 — Twitter・GoogleなどがシンプルなAPIキー方式でAPIを公開し始め、広く普及。
2010年 — OAuth 1.0a（RFC 5849）が標準化。署名ベースで安全だが実装が複雑だった。
2012年 — OAuth 2.0（RFC 6749）公開。実装がシンプルになり、Facebookログイン・Googleログインなど「ソーシャルログイン」が爆発的に普及。
2015年 — JWT（RFC 7519）が標準化。マイクロサービスアーキテクチャの広がりとともにAPI間認証の主流に。
2020年代 — OpenID Connect（OAuthの上にユーザー認証を乗せた規格）とJWTの組み合わせがクラウドSaaS連携の事実上の標準となる。ゼロトラストセキュリティの普及でmTLSへの注目も高まる。

OAuth 2.0とJWTの関係・フロー図

OAuth 2.0とJWTはよく一緒に使われますが、役割が異なります。OAuth 2.0は「誰に何を許可するか」のフロー（手順）を定めた仕様で、JWTはその結果発行されるトークンの形式です。

APIキー vs OAuth 2.0：どちらを選ぶ？

比較項目	APIキー	OAuth 2.0 + JWT
実装の簡単さ	◎ 非常に簡単	△ 設計・実装コストが高い
トークンの有効期限	✕ 期限なし（手動で変更要）	◎ 自動で期限切れ
権限の細かさ	✕ キー単位でしか制御できない	◎ スコープで細かく制御
漏洩時のリスク	高（即時無効化が必要）	低（短期トークンなら被害限定的）
向いている用途	社内ツール・PoC・低リスクAPI	本番SaaS・外部公開API・個人情報を扱う連携

規格・RFC番号	内容
RFC 6749	OAuth 2.0 認可フレームワークの仕様
RFC 6750	OAuth 2.0 Bearer トークンの使用方法
RFC 7519	JWT（JSON Web Token）の仕様
RFC 7517	JWK（JSON Web Key）：JWTの鍵管理仕様
RFC 7521	OAuth 2.0 クライアント認証へのアサーション使用
RFC 8705	OAuth 2.0 相互TLS（mTLS）クライアント認証
RFC 5849	OAuth 1.0a（旧バージョン、参考）