2026.09.02 プロトコル

API認証の設計｜方式選定マトリクスとトークン寿命・監査ログの決め方

API認証の設計とは、APIを呼び出してきた相手が名乗るとおりの存在かを確かめる仕組みを、方式・資格情報の寿命・検証を実行する層・記録の4点で決める作業です。実務で詰まるのは方式の中身より「自社のこのAPIではどれを選ぶのか」という判断のほうでしょう。この記事では、APIキー・Basic認証・OAuth 2.0・JWT・mTLSを適用条件のマトリクスへ整理し、社内APIと公開APIでの分岐、トークン寿命と失効の決め方、監査ログに残す項目、既存APIの移行手順までを判断の順に並べます。

まとめ：API認証の設計で先に決める4点と判断の順序

決めるのは4点です。何を検証するか（利用者か、呼び出し元アプリか、その両方か）、どの方式を使うか、資格情報の寿命と失効手段、そして検証をどの層で実行してどう記録するか。この順に固定してください。方式の比較から議論を始めると、検証対象が曖昧なまま「JWTか、セッションか」という技術選定に入り込み、結論が出なくなります。

公開範囲ごとの既定値は次のとおり。社内APIならゲートウェイでのトークン検証と呼び出し元IDの伝播、パートナー向けならクライアント資格情報フローと契約単位の権限、外部公開でユーザーの代理アクセスが発生するなら認可コードフローとPKCE、サービス間通信ならmTLSか短命トークン。ここから外れる要件が出たときだけ個別に検討すれば足ります。

作り込みの深さは「資格情報が漏れたとき、影響範囲を誰がどれだけの時間で止められるか」で決めてください。単一の社内クライアントしか呼ばないAPIなら、TLS上のAPIキーと失効手段だけで打ち切ってよい場面もあります。逆に、呼び出し元が増え続ける、ユーザー単位の権限が要る、監査を第三者へ説明する必要がある、のどれかに該当した時点で認可基盤を前提にした設計へ切り替えます。

API認証の設計とは何を決める作業か：認証・認可・監査の切り分け

設計を始める前に、扱う範囲を確定させてください。API認証という言葉には性質の違う3つの話が混ざっており、切り分けないまま方式を選ぶと、方式では解決できない要件を方式で解こうとして手が止まります。

利用者の認証と呼び出し元アプリの認証を分けて考える切り分け方

最初の分岐は、検証したい相手が「人」なのか「アプリケーション」なのかです。APIキーが識別できるのは呼び出し元アプリだけで、その先にいるエンドユーザーは分かりません。OAuth 2.0のクライアント資格情報フローも識別の対象はアプリです。

ここを混同すると、APIキーの発行単位をユーザーごとに増やして権限を分ける設計が生まれます。キーの本数が利用者数に比例して増え、失効も棚卸しも手に負えなくなる構成です。ユーザー単位の権限が要るなら、利用者を認証して主体をトークンへ載せる委譲フローが要ります。両方が要る場合は「どのアプリが」「どのユーザーの代理で」の2軸をトークン内で別々に表現します。

認証と認可と監査を別レイヤーに分けると、方式選定の順序が決まる

次の切り分けは、認証（誰か）・認可（何をしてよいか）・監査（何をしたか）の3層です。方式が担当するのは認証と、せいぜいスコープという粗い粒度の認可までにとどまります。

「このユーザーはこの注文データを閲覧してよいか」といったリソース単位の判定は、どの認証方式を選んでもアプリケーション側の実装として残るもの。リスク起点の整理はAPIセキュリティとは？OWASP API Top 10の主要リスクと実装対策を解説にまとめてあります。

3層に分けると、認証で主体を確定させ、その主体を認可判定へ渡し、判定結果を監査へ残すという順序が決まります。ここが固まっていれば、方式が変わっても認可と監査は作り直しになりません。工程全体の枠組みはAPI設計とは？リソース定義からURI・スキーマ・エラー・版管理までの実装手順で扱っています。

5方式の適用条件マトリクス：APIキー・OAuth・JWT・mTLSの選び分け

方式ごとに識別できる対象と向く場面が違います。先に一覧で押さえてから採用条件を見ていきます。

方式	識別できる対象	向く場面	主な弱点
APIキー	呼び出し元アプリ	社内・少数の契約先	長期の固定値になる
Basic認証	アカウント	暫定・管理系の内部API	毎回パスワードを送る
OAuth 2.0	アプリと利用者	外部公開・権限委譲	認可基盤の運用が要る
JWT	トークンの発行元	検証を分散したい構成	即時失効ができない
mTLS	クライアント証明書	サービス間・閉じた相手	証明書の更新運用

APIキーとBasic認証を採用してよい条件と、外してはいけない場面

APIキーを採用してよいのは、3つの条件がそろうときです。呼び出し元がサーバ側で動いていて資格情報を安全に保管できること、相手が少数で契約や社内規程で縛れること、ユーザー単位の権限判定が不要なこと。この範囲なら実装の軽さに見合います。

外すべき場面もはっきりしています。ブラウザで動くJavaScriptやモバイルアプリへ埋め込む用途では、配布物からキーが取り出せてしまうため成立しません。ユーザーごとに見せるデータを変える要件がある場合も同様。キー自体の発行・保管・失効の手順はAPIキー管理とは？発行・保管・失効とローテーションの実装を解説へ分けてあります。

Basic認証（RFC 7617）は、リクエストのたびにIDとパスワードを送る方式です。TLS前提なら通信路上の保護は成立するものの、資格情報がパスワードそのものであるため、漏洩時に人のアカウントごと入れ替える羽目になります。管理系の内部APIか暫定用途に限る位置づけでしょう。

OAuth 2.0を選ぶ条件は、第三者への権限委譲が発生するかどうか

OAuth 2.0は、利用者が自分の権限の一部をアプリケーションへ委譲するための枠組みです。判断基準は単純で、自社以外のアプリがユーザーの代理でAPIを呼ぶ場面があるかどうか。あるなら採用、ないなら過剰になることがあります。

ただし、既にIDaaSや認可サーバを社内で運用しているなら、自社クライアントだけの構成でもOAuthへ寄せる判断が成り立ちます。トークンの発行・検証・失効を一箇所へ集約でき、APIごとに認証コードを書かずに済むためです。

フローの選択では、認可コードフローとPKCE（RFC 7636）の組み合わせを既定に置きます。サーバ間の呼び出しにはクライアント資格情報フロー。インプリシットフローとリソースオーナーパスワードクレデンシャルズは、RFC 9700（OAuth 2.0 Security Best Current Practice・2025年1月発行）が使用しない方向を示しており、新規の設計で選ぶ理由はありません。これらの推奨を取り込んだOAuth 2.1は2026年9月時点で後期ドラフトの段階にありRFC未発行のため、現行のRFC 9700に沿って実装しておけば移行時の差分は小さく収まります。各フローの流れはOAuth 2.0とは？仕組み・認可フローと認証・認可の違いをわかりやすく解説で確認できます。

JWTを検証方式に選ぶ判断と、失効要件が崩す自己完結という前提

JWT（RFC 7519）は認証方式ではなく、トークンの表現形式です。「JWTにするか、OAuthにするか」という比較の立て方自体が噛み合っていません。正しくは、OAuthで発行するアクセストークンの中身をJWTにするか、認可サーバへの問い合わせが必要な不透明トークンにするか、という選択です。

JWTを選ぶ利点は、署名を検証できれば認可サーバへ問い合わせずに済むこと。API側がスケールしても検証がボトルネックになりません。代償は、発行済みトークンを即座に無効化できない点です。失効の要求が出ても、有効期限が切れるまではそのトークンで通ります。

したがって判断基準は「失効の反映に何分の遅れを許容できるか」の一点。数分の遅延を許容できるなら短い有効期限を組み合わせて成立し、即時失効が要件なら不透明トークンとイントロスペクション（RFC 7662）の構成へ倒します。両者の使い分けはトークンイントロスペクションとは？RFC 7662の検証とJWT方式の使い分けを解説、構造と署名検証の実装はJWTとは？構造・署名検証の仕組みとセッション・OAuth/OIDCとの違いを実装視点で解説にあります。

mTLSを選ぶのはサービス間通信で相手が事前に確定する場合に限る

mTLSは、サーバだけでなくクライアントも証明書を提示して相互に検証する方式です。通信路の確立時点で相手が確定し、アプリケーション層の資格情報を持ち回らずに済みます。

採用条件は3つ。通信の相手がサービスやシステムであること、相手の集合が事前に確定していること、証明書の発行・配布・更新を回す運用体制があること。マイクロサービス間や金融系の相互接続のように相手が固定される経路では有力な選択です。逆に、不特定多数のブラウザ利用者が相手では証明書の配布が成立しません。

OAuthと組み合わせる使い方もあります。RFC 8705の証明書バウンドトークンは、アクセストークンをクライアント証明書へ結び付け、盗んだだけでは使えない状態を作る仕組み。証明書の運用と導入判断はmTLSとは？相互TLS認証の仕組みとクライアント証明書・導入判断を実装目線で解説にまとめてあります。

公開範囲で方式を決める：社内API・パートナー・公開APIの分岐

方式の比較表だけでは選定が決まりません。決め手になるのは、そのAPIを誰が呼ぶのかという公開範囲です。範囲ごとに既定値を持っておくと、案件ごとの検討時間が短くなります。

社内APIで認証をゲートウェイへ寄せてよい条件と、残る実装責務

社内APIでは、認証の検証をAPIゲートウェイへ集約する構成が扱いやすくなります。各サービスが検証コードを持たずに済み、方式変更の影響もゲートウェイの設定に収まるためです。

ただし、寄せてよいのは「ゲートウェイを迂回した直接呼び出しが構成上できない」場合に限られます。サービスのポートが露出していて内部からなら認証なしで叩ける状態では、集約が防御になっていません。ゲートウェイとリバースプロキシ・サービスメッシュの境界はAPIゲートウェイとは？役割・機能とリバースプロキシ／サービスメッシュとの違い・導入判断を解説で整理しています。

パートナーAPIと公開APIで変わる資格情報の配布と権限の粒度

パートナー向けAPIの特徴は、相手が契約で確定していて呼び出し元がサーバである点。この条件ならクライアント資格情報フローが素直に収まります。権限の粒度は契約単位で切り、パートナーごとにクライアントを分けて発行してください。勘所は、資格情報の受け渡し方法と、担当者の交代に耐える更新手順を先に決めておく点にあります。

不特定多数へ開く公開APIでは前提が変わります。呼び出し元アプリを事前に把握できず、モバイルアプリやSPAのように資格情報を秘密にできないクライアントが混ざるためです。認可コードフローとPKCEを既定にし、スコープはAPIの機能単位ではなく利用者が理解できる粒度で切ります。読み書きを分ける程度の粗さから始め、必要に応じて分割する進め方が現実的。最初から細かく切ると同意画面が読めなくなります。

アクセストークンの寿命・失効・ローテーションを数値で決める手順

方式が決まったら次は資格情報の寿命です。決めないまま実装へ入ると、有効期限が既定値のまま本番へ出て、事故が起きてから慌てて短くする羽目になります。

アクセストークンの寿命を決める2つの基準と、失効遅延の許容範囲

寿命を決める基準は2つ。1つ目は、盗まれたトークンが使える時間をどこまで許容するか。2つ目は、更新処理の頻度がクライアントとネットワークにかける負荷です。前者だけなら短いほどよく、後者を見れば長いほど楽になるという相反する軸を、数値で折り合わせます。

実務では、自己完結型のトークンで数分から十数分程度、更新に使う長期のトークンは日単位から週単位という置き方が多く見られます。ただしこれは出発点の目安で、要件から逆算するのが本筋。まず「権限を剥奪してから締め出されるまで何分なら説明がつくか」を業務側と決めて寿命の上限に置き、次にその頻度で更新が飛んだときの負荷を見積もる。耐えられなければイントロスペクションの併用へ切り替えます。

長期の資格情報を持たせず、短命トークンへ交換する構成の作り方

設計の方向としては、長期間有効な資格情報をクライアントやサーバに置かない形を目指します。長期のキーを持たせると、それが漏れた時点で防ぎようがなくなるためです。

取れる手は2つ。1つは、長期の資格情報を認可サーバ側にだけ置き、クライアントには短命のアクセストークンと更新用のトークンを渡す構成。更新フローと再利用検知を含む寿命設計はリフレッシュトークンとは？更新フローと寿命・ローテーション設計を実装者向けに解説で扱っています。もう1つは、実行環境が持つ身元情報を短命トークンへ交換する構成。クラウド上のワークロードなら、環境側が発行する署名付きの身元情報を認可サーバへ提示してその場でトークンを受け取る形にすれば、静的なキーを配布せずに済みます。

どちらの構成でも、更新に失敗したときクライアントを再認証へ倒すのか一定回数まで再試行するのかを決めておいてください。未定義だと、認可サーバの一時的な不調がそのまま全クライアントのログアウトへつながります。

API認証をどの層で実行するか：ゲートウェイとアプリの責務分担

方式と寿命が決まっても、検証をどこで実行するかが曖昧だと、同じ検証が二重に走ったり、どこでも検証されない経路が残ったりします。層ごとの責務を明文化しておきます。

ゲートウェイで検証しアプリで認可する分担と、内部呼び出しの扱い

基本の分担は、トークンの署名検証・有効期限・スコープの確認までをゲートウェイ、リソース単位の判定をアプリケーションに置く形。ゲートウェイは検証済みの主体情報をヘッダーへ載せて後段へ渡し、アプリはそれを信頼して認可判定に使います。

この構成が破綻するのは、後段のサービスがゲートウェイ以外からも到達できるときです。ヘッダーに載った主体情報は、直接呼び出せる相手なら偽装できます。対処は、到達経路をネットワークでゲートウェイ経由へ限定するか、後段でも署名を検証して主体を確認するかの2つ。サービス間呼び出しが多い構成なら、内部通信をmTLSで固める選択もあります。

もう1つは呼び出し元IDの伝播です。サービスAがサービスBを呼ぶとき、元の利用者をBまで伝えないと監査ログにサービスAしか残りません。トークンをそのまま転送するか専用のクレームで元の主体を運ぶかを、設計段階で統一してください。検証に失敗したときの応答（401と403の使い分け、返してよい情報の粒度）はAPIエラーレスポンス設計とは？コード体系・リトライ判断・漏洩防止の実装手順の領分です。

監査ログの設計：認証イベントで残す項目と保持期間・検知の判断基準

認証の設計は記録まで含めて完成します。不正なアクセスが疑われたとき、誰がいつどの資格情報で何を呼んだかを追えなければ影響範囲を確定できないためです。

認証イベントで残す6項目と、ログに記録してはいけない値の線引き

残す項目は6つを基本形にします。発生時刻（タイムゾーンを明示した形式）、呼び出し元の識別子（クライアントIDと、利用者を伴う場合はその主体識別子）、リクエストの相関ID、判定結果と失敗時の理由コード、接続元のIPアドレスとユーザーエージェント、対象リソースの識別子。これだけあれば、失敗の連続や普段と違う経路からの成功を追えます。

記録してはいけない値の線引きも同時に決めてください。アクセストークンやAPIキーの値そのもの、Authorizationヘッダーの生の内容、パスワード、トークンに含まれる個人情報。ログ基盤は保管期間が長く閲覧者も多いため、資格情報が流れると盗まれる経路を増やすことになります。追跡に識別が要るなら、ハッシュ値や末尾数文字といった復元できない形へ落とします。

保持期間は監査要件と障害調査の実用性から決めます。調査でさかのぼるのは直近数週間が大半ですが、不正利用の発覚が数か月遅れる前提なら認証イベントだけは長めに残す設計が要ります。検知については、単位時間あたりの認証失敗回数、通常と異なる国からの成功、失効済みトークンの提示回数といったしきい値を先に決め、超えたときの通知先まで運用へ載せてください。

過剰設計になる条件と、既存APIの認証方式を移行する判断ライン

認証は作り込もうとすればいくらでも深くできます。どこで止めるか、いつ次の方式へ移るかを条件として持っておきます。

認可基盤を内製せずIDaaSへ寄せる判断と、社内実装が残る領域

認可サーバを自前で実装する判断は慎重に扱ってください。トークン発行、鍵の管理と入れ替え、同意画面、失効、各種フローへの追随が絡み、RFC 9700のような推奨事項の更新にも追従が要ります。

既製のIDaaSや認可サーバ製品へ寄せる判断が成り立つのは、標準的なフローで要件が満たせる場合です。内製を検討するのは、既存の社内認証基盤と密結合していて外部製品では表現できない権限モデルがある、といった限定的な場面に絞られます。ID管理側の全体像と製品類型は認証・ID管理とは？多要素認証・SSO・OIDC・IDaaSの違いと選び方にまとめました。

寄せた場合でも社内実装が残る領域があります。リソース単位の認可判定、監査ログの設計と保管、自社の業務モデルに沿った権限の定義です。製品を導入しても消えないため、工数見積もりから外さないでください。方式選定から認可基盤の接続、既存APIの移行まで外部と進める場合は、API開発・システム連携のように連携設計から実装まで一貫して扱う体制を持つ相手を選ぶと、認証だけが宙に浮く事態を避けられます。

APIキー運用からOAuthへ移行する条件と、無停止で切り替える手順

キー方式で運用中のAPIについて、移行を検討する条件は3つ。呼び出し元が増えて棚卸しが追いつかない、ユーザー単位の権限が要件に入った、キーの失効を短時間で行う必要が出た。どれか1つでも当てはまれば移行の検討段階です。

切り替えは一斉には行いません。まず新方式のトークン検証を既存の認証と並べ、両方式を同時に許可する期間を設けます。次に新規の利用者は新方式のみで登録し、既存の利用者へ移行期限を通知。移行状況をキー単位で追跡し、未移行が残る間は旧方式を残します。期限到来後は旧方式を拒否へ切り替え、それでもキーは即削除せず一定期間は失効済みとして記録に残す。この形なら、どのキーがいつ止まったかを後から説明できます。

見落としやすいのが監査ログの互換性です。主体識別子がキーIDからクライアントIDへ変わると前後で追跡が途切れるため、両方式の期間はどちらも残るようスキーマを先に広げておいてください。