APIセキュリティとトークン

概要

APIセキュリティは、認証、承認、暗号保護、不正使用防止、およびオブザビリティメカニズムのコレクションであり、要求が期待されるリソースに期待されるエンティティを確実に実行することを保証します。キーアーティファクトは、呼び出す権利を証明するトークン（またはリクエスト署名）です。優れたアーキテクチャは、短命のトークン、明確なスコープ、最小限の特権、リプレイ保護、レート制限、運用手順（回転、監査、インシデント）に依存しています。

API認証モデル-いつ、何を選択するか

APIキー（静的秘密）

B2B統合と低リスクのシナリオのためのシンプル。コンテキストを運ばない、サービス側のストレージが必要です。
IP/ASN allow-list、固定クォータ、短いTTLおよび回転でのみ使用できます。

OAuth 2。1/OIDC

ユーザーとパートナーの統合のための標準：アクセストークン（短期）+リフレッシュトークン（回転）+スコープ。
パブリッククライアント-PKCE；機密クライアント-クライアントシークレット/mTLS。

クライアント資格情報（m2m）

Mashina→mashina：厳密に定義されたスコープとオーディエンス上のサービスのアクセストークン、多くの場合、更新なし（再度取得）。

mTLS（相互TLS）

チャンネルにIDをバインドします。ハイリスクまたは支払い統合（PoP over TLS）に最適です。
OAuthと組み合わせることができます（トークンはmTLSクライアントのみ）。

署名を要求する（HMAC/EdDSA）

トランスポートに依存しないPoP：署名ヘッダ、タイムスタンプ、およびノンスが必要な場合。Webhookとオフライン検証に便利です。

トークンの形式と種類

JWT （JWS、署名済み）

ローカルに点検される自給自足；'iss'、 'sub'、 'aud'、 'exp'、 'iat'、 'jti'、 'scope'が必須です。
リスク-より困難なリコール：短いTTL （5-15 min）+リコールされた'jti'のリストをインシデントで使用します。

JWE（暗号化されたJWT）

ペイロードがセンシティブ（PII）である場合に必要です。コスト-複雑さとオーバーヘッドが増します。

リファレンストークン

不透明な識別子は、Authorization Serverによるイントロスペクションによってチェックされます。

PoP/DPoP

トークンをクライアントキーまたはTLSセッションにバインドすると、盗まれたトークンの値が減少します。

トークンコンテンツ： 最小十分

推薦された切手（JWT）：

'iss'（発行者）、'sub' （subject）、 'aud' （target system/resource）、 'exp' （term）、 'iat'、 'nbf' （optional）、 'jti'。
'scope'/'permissions'（最低必要）、'tenant'（マルチテナント用）、'device_compliant'/'amr'（認証方法）、'ip'/'asn'（ポリシーに該当する場合）。

ルール：

アクセスのための短いTTL （5-15分）、リフレッシュ-12-48 h（回転回転と）。
オーディエンス（'aud'）は厳密に特定のリソースであり、そうでなければトークンは「再利用可能」です。
スコープ-アクションとオブジェクト（例えば、'payment： withdraw。read'）。
サイズ-ヘッダーおよびプロキシのための≤ 2-4 KB；そうでなければゲートウェイに問題があるかもしれません。

承認とポリシー

RBAC+ABAC： role+context（組織、地理、リスク、デバイスのステータス）。
PEP/PDPトークンの検証とAPIゲートウェイ/プロキシ（Envoy/OPA）の決定。
宣言ルール：Gitに保存し、CIでポリシーテストに合格します。

Regoの例（簡略化）：

rego package policy. withdraw

default allow = false

allow {
input. token. aud == "wallet-api"
input. token. scope[_] == "payments:withdraw. create"
input. device. compliant == true input. risk. score < 70
}

リクエスト署名（HMAC）とアンチリプレイ

必要に応じて：webhook、 OAuthなしの統合、重要な操作をダブルチェックします。

ヘッダースキーマ（例）：


X-Client-Id: <id>
X-Timestamp: 2025-11-05T13:20:10Z
X-Nonce: 4d1f...a2
X-Signature: base64(HMAC_SHA256(secret, method + "\n" + path + "\n" + sha256(body) + "\n" + timestamp + "\n" + nonce))

ルール：

タイムミスアライメント>± 300秒で要求を拒否します。
Nonceは5〜15分間保存し、リプレイ（リプレイキャッシュ）は受け付けません。
正規化されたクエリビュー（メソッド、パス、クエリ、ボディハッシュ）に署名します。

アイデンティティとトランザクション保護

Idempotency-Key for write-off/pay-out/create operations：同じキー→同じエフェクト。
主要な寿命は≥のビジネスのタイムアウト時間（通常24-72時間）です。
「サーバーサイドロジック」（Server-side logic）-クエリパラメータを以前にこのキーにコミットしたものと比較します。

ブラウザとモバイルクライアント

PKCEは必須です（パブリッククライアント）。
ブラウザでトークンを更新する-避ける；必要に応じて-ROTATION+リプレイ応答（リプレイ検出）。
ストレージ：セッションストレージ>ローカルストレージ；より良い-フロントエンド（BFF）のバックエンドはトークンの責任を負います。
SameSite、 Secure、 HttpOnlyクッキー；CORS：明示的な許可リスト、ヘッダー、メソッド。プリフライトキャッシングは安全です。

m2mおよび高リスクの統合

mTLS+OAuth2 Client Credentials with scopes and 'aud'。
ゲートウェイのIP/ASN allow-list。
重要な操作のためのTLS上のPoP/DPoPまたはHMAC署名。
組織/クライアント/キーごとのクォータとレート制限。

回転、リコール、インシデント応答

SecretとSignature Key Rotation （JWKS）： scheduled+enforced on incident。
デュアルキーロールアウト：新しいキーペアを事前に公開し（kid2）、トークンに署名し、TTLが使い果たされるまで検証のために古いキーワード（kid1）を保持します。
リフレッシュローテーション：すべてのリフレッシュ交換→新しいトークン、古いトークンはすぐに無効になります。繰り返し-妥協信号。
失効：JWTの場合-リコールされた'jti'の一覧;リファレンストークンの場合-ASを即座にブロックします。
ブレークガラススクリプト：最小限の権利とハードTTLを持つ一時的な静的クレジット、ログに記録します。

制限率、ボット保護とブルートフォース保護

3層の制限：キーごと/IPごと/組織ごと。
バースト+持続：トークンタンク/スライディングウィンドウ。
複雑なチェック：デバイス指紋、行動信号、地理/ASN異常、UIのみのCAPTCHA。
シグネチャ/NMACの再ネゴシエーションと認証の試行時にロックアウト/スローダウンが失敗する。

ロギング、メトリック、SLO

ログの最小セット：'request_id'、 'client_id'、 'sub'、 'aud'、 'scope'、 'decision'、 'reason'、 'jti'、 'ip'、 'asn'、 'latency'、 'quota_state'。

メトリクス：

トークン検証の成功（％）、p95検証時間。
リプレイの偏差の頻度、Idempotency-Keyの重複。
PoP/DPoP/mTLSによるリクエストの割合。
'aud/scope'エラー、期限切れの'exp'、タイムシフト（NTP）。

SLO（例）：

Auth/AS ≥ 99の可用性。95％/月；p95イントロスペクション≤ 50ミリ。
prod（ガードメトリック）でTTL <60 sのゼロトークン。
0未満。1日あたりの'aud/scope'エラーの1％（統合の質）。

設定例

特使： JWTとオーディエンスチェック

yaml http_filters:
- name: envoy. filters. http. jwt_authn typed_config:
providers:
as:
issuer: https://auth. example. com/
audiences: ["wallet-api"]
remote_jwks:
http_uri:
uri: https://auth. example. com/.well-known/jwks. json cluster: jwks_cluster cache_duration: 600s rules:
- match: { prefix: "/v1/withdraw" }
requires:
provider_and_audiences:
provider_name: as audiences: ["wallet-api"]

NGINX： mTLS-バックエンド

nginx proxy_ssl_server_name on;
proxy_ssl_name wallet. internal;
proxy_ssl_certificate   /etc/nginx/mtls/client. crt;
proxy_ssl_certificate_key /etc/nginx/mtls/client. key;
proxy_ssl_trusted_certificate /etc/nginx/mtls/ca. crt;
proxy_ssl_verify on;
proxy_ssl_verify_depth 2;

署名ヘッダの例（webhooks）


X-Signature: t=1730803210,n=ac12...,s=base64(HMAC_SHA256(secret, "POST\n/webhook\nsha256(body)\n1730803210\nac12..."))

't'が300 cより古い場合、'n'が既に満たされている場合、または's'が破損しない場合、サーバは拒否します。

データ保護とプライバシー

ホールマーク（特にPII）と寿命を最小限に抑えます。
サードパーティの統合のための機密スタンプ（JWE）を暗号化します。
ログ内のマスク/DLP： PAN/PII、トークンで本体をログに記録しないでください。

よくあるエラー

長寿命のアクセストークンと「永遠」リフレッシュ。
'aud'/' scope'→トークンがない場合は多目的です。
'timestamp'/'nonce'のないwebhookの署名。
ゲートウェイ（PEP）ではなく、アプリケーションでのみJWTをチェックします。
回転および二重キーのロールアウト無し。
「CORS」とヘッダー制御なしで安全でないメソッドを許可。
BFFなしで'localStorage'にトークンを格納します。

実装ロードマップ

1.APIインベントリと分類（パブリック/パートナー/内部、感度）。
2.AuthNモデル選択：カスタムのOAuth2/OIDC、 mTLS+Client Credentials/m2mのHMAC。
3.トークン：短いTTL、厳密な'aud'、スコープ、重要な操作のためのDPoP/PoP。
4.ゲートウェイのPEP： JWT検証、署名、およびアプリのレート制限。
5.アンチリプレイとidempotency： timestamp/nonce/Idempotency-Key。
6.回転とJWKS：デュアルキー、オートメーション、アラート。
7.観測可能性：メトリック/SLO、アクセスログ、UEBA信号。
8.演習：署名キー、リフレッシュリーク、クォータ過負荷。

iGaming/Fintechの特異性

支払い/支払い：mTLS+PoP/HMACのみ、厳格なスコープ（'出金。create'）、idempotencyが必要です。
パートナー（PSP/コンテンツプロバイダ）：パートナーキー/証明書、IP/ASN許可リスト、個々のクォータおよびダッシュボード。
GDPR/PCI DSS：スタンプの最小化、サードパーティトークンのPIIの禁止、機密リソースへのログアクセス、定期的なアクセスレビュー。
反乱用：行動制限、ジオコントロール、APIレベルでのボーナス乱用に対する保護。

よくあるご質問

JWTまたはリファレンストークン？
JWT-パフォーマンスと自律性。リファレンス-インシデント対応の一元化されたフィードバックとシンプルさ。多くの場合、ハイブリッド：外部-JWT、内部-参照。

JWEは必要ですか？
ペイロードにPII/secretsが含まれている場合のみ。それ以外の場合-最小のホールマークを持つJWS。

APIキーで生活できますか？
はい。ただし、短いTTL、厳密なクォータ、IP-allow-list、およびリクエスト署名のみを使用します。ユーザーには、OAuth/OIDCが推奨されます。

DPoP/PoP必須？
必ずしもそうではありません。しかし、高リスクのオペレーション（支払い、結論）は非常に望ましいです。

合計

信頼性の高いAPIセキュリティは、短命のトークン、正確なスコープとオーディエンス、セキュアチャネル（TLS/mTLS）、リクエスト署名、および制限とオブザビリティによって強化された厳格なアンチリプレイ保護に基づいて構築されています。自動ローテーション、デュアルキーロールアウト、ゲートウェイの政治制御を追加します。APIは、高いパフォーマンスと管理性を維持しながら、リーク、リプレイ、悪用に耐性があります。