REST APIセキュリティ：HMAC /キーハッシュとJWT

私はこの記事読んで数年前ですが、あなたのREST APIを確保する巧妙な方法を説明します。基本的に：

• 各クライアントには一意の公開/秘密キーペアがあります
• クライアントとサーバーのみが秘密鍵を知っています。有線で送信されることはありません
• 各リクエストで、クライアントはいくつかの入力（リクエスト全体、現在のタイムスタンプ、およびプライベートキー）を受け取り、それらをHMAC関数で実行してリクエストのハッシュを生成します
• 次に、クライアントは通常のリクエスト（公開キーを含む）とハッシュをサーバーに送信します
• サーバは（提供された公開鍵に基づいて）クライアントの秘密鍵を検索し、要求はの被害者ではないことを検証（確かに私は理解していないことを）いくつかのタイムスタンプのチェックを行い、リプレイ攻撃
• すべてが順調であれば、サーバーは秘密鍵と同じHMAC関数を使用して、リクエストの独自のハッシュを生成します
• 次に、サーバーは両方のハッシュ（クライアントが送信したハッシュとクライアントが生成したハッシュ）を比較します。それらが一致する場合、要求は認証され、続行が許可されます

それから私はJWTを偶然見つけました。ただし、最初の記事ではJWTについてまったく言及していないため、JWTが上記の認証ソリューションと異なるのかどうか、またそうである場合はその方法について疑問に思っています。

非常に基本的な答えから始めましょう。

JWT（OAuthおよびOpenIDのコンテキストで使用される）は、クライアントとAPIの間で共有シークレットを必要としません。3つのコンポーネントがあり、2つのペアがそれぞれ秘密を共有します：クライアント<->識別サーバー、識別サーバー<-> API。

これにより、ほとんどの複雑さがAPIから識別サーバーに移動します。APIは、トークンが識別サーバーによって発行され、調整されていないことを確認するだけです。APIが、識別サーバーとAPI間の既知の単一共有シークレットでJWT署名が有効であることを確認することを確認します。それでおしまい！

識別サーバーがユーザーIDを検証する方法は大きく異なります（多くの場合、TLS接続上の古いユーザー名とパスワードのペアです）が、APIには影響しません。

JWTを使用する場合のメッセージとトークン自体のプライバシーとセキュリティはTLSによって処理され、JWTはそのような問題を認識しません。