（JWTの代わりに）公開APIでの認証にAPIキーを使用する必要がありますか？
公開APIを構築しています。このAPIの消費者は私たちのビジネスパートナーになります-私たちはおそらくそれぞれと個人的な関係を持ち、これらの顧客は10〜40人しかいないと思います。したがって、私たちは同じ問題に対処していません。 Spotify/Facebookは、公開APIを使用する場合があります。
各ユーザーに異なるAPI読み取り権限を与えたいので、ある程度の認証が必要です。
各顧客にAPIキーを発行し、関連する権限をテーブルに格納します。しかし、これを処理するためにJWTを実装する必要があるのか（またはOAuthのような別のオプションでさえ）疑問に思っています。
APIキーの長所：
- シンプル。クライアントが実装しやすい（私たちにとってかなり重要）
- Auth呼び出しが少なくなるため、レート制限が簡単になります。
- 安価（AWSラムダを使用しているため、リクエストごとに支払います）
- 私たちも構築するのが速い
JWTの長所
- 承認を処理するためのより確立された方法。ホイールを再発明する必要はありません。
- 独自のアクセスメカニズムの実装に関する予期しない落とし穴を回避する
- 私たちの側でのデータベース検索の数が少ない（ただし、全体的にフローが遅いと思われる）
- ...ここで見逃したものはありますか？
単純化のためにAPIキーを使用していますが、重要なものを見落とさないようにしたいと考えています。
APIキーは、実際にはJWT（2010年にのみ標準化された）よりも古い認証の規則だと思います。あなたは確かにそれらを使用するためにホイールを再発明していません。このシナリオは間違いなくそれらを使用するのに熟練しているようですが、JWTは実際にはかなりの不必要な複雑さを追加すると思います。
JWTは特定の認証や承認のシナリオで特に価値がありますが、それらのどれもここでは適用されないと思います。認証と承認を分離していないと思われます（JWTでは、ある当事者がユーザーを認証し、次に別の当事者がそれに基づいてサービスを提供または拒否することができます）。小さなプールまたはユーザーを維持していて、おそらくアクティブな接続と要求レートがほとんどないため、要求ごとに1つのデータベース（または実際にはデータキャッシュ）ルックアップをカットすることは、緊急ではありません。パートナーが複数のトークンをそれぞれ最小限の権限セットで期待しているとは思えないようです。一部のシナリオではより安全ですが、実装は間違いなく複雑です-とにかくAPIキーでそれを行うことができます。
一方、JWTには重大なリスクがあります。 JWT解析ライブラリは、APIキーを思い付かないいくつかの攻撃に対して安全である必要があります（これらには独自のリスクがありますが、それらは主にSQLインジェクション、ブルートフォーシング、タイミング攻撃などのよく知られたものです）。 JWTには、暗号化キーの生成、保存、使用、およびローテーションが必要です。また、認証プロバイダーとサービスプロバイダーを分離している場合は、それらを配布する必要があります。 JWTは取り消すのが難しいため、通常は有効期間が短いため、いくつかのother認証トークン（DBに格納された更新トークンのような）または低摩擦の認証方法をサポートする必要があります。とにかくAPIキーを使用する必要があるかもしれません。
別のオプション（顧客またはAPIに適している場合とそうでない場合があります）は、TLSクライアント証明書を使用することです。これらは、説明したどちらのアプローチよりも安全です（個別に発行および失効したキーの制御と単純な処理、組み込みの有効期限、およびJWTの総当たり攻撃の不可能性）。また、実際のシークレットをTLSトンネル内でも配線し、「誤ってプレーンテキストでトークンを送信する」ことは、意味のあるリスクでさえありません）。ただし、欠点もあります（キーマテリアルの処理が必要で、登録が複雑になり、個々のユーザーが複数のデバイスへのアクセスを有効にするのが難しくなります。侵害が発生した場合、ローテーションはより複雑になる可能性があります。ユーザーはあまり慣れていません）それら）。非常に少数のユーザーとそれらのユーザーとの協力関係を期待していることを除いて、私はそれについてさえ言及しません。