0

最初に言っておきますが、これはクライアント トークンとサーバー側のセッション参照の問題ではありません。私は違いを理解しており、セッションレスの実装を既に決定しています。

また、localStorage、クエリ パラメータ、認証ヘッダーなどではなく、クライアント側の永続性と送信に Cookie を使用することにしました。

わかりました。それで、クライアントにユーザー ID を保存するための 2 つの代替案を検討しています。どちらも、データの署名による改ざんを防ぎます。

Express には、署名付き Cookie を有効にするミドルウェアがあります。または、データに署名する JWT を使用することもできます (これも Cookie 経由で送信します)。

これまでのところ、署名付き Cookie を使用することを考えています。処理のオーバーヘッドが少なく、特定のことを行います。ネストされた json 形式のデータは必ずしも必要ではありません。また、API やその他の承認ではなく、Web サーバーでのユーザーの認証にのみ使用しています。公開/秘密の非対称キーの検証は必要ありません。

JWT は優れた標準であり、私はすでに OAUTH に使用していますが、私のサイト認証には、いくつかの利点は必要ありません。たとえば、転送可能性には必要ありません。異なる署名アルゴリズムやトークン タイプはありません。

ただし、JWT が認められた標準であり、多くのサポート/ドキュメントがあることを高く評価しています。

Web サイトの承認とクライアントの識別に JWT を使用することを選択する必要がある理由について、私が見逃しているものはありますか?

ところで、質問を投稿する前に、これについて調査しました。これは非常によく似たものです。トークンベースの認証のための JWT と Cookie の比較です。

ただし、トップ投票の回答はいくつかの理由で当てはまりません。主に、JWT に Cookie を使用するかどうかは既に決めています。CSRF 攻撃を防ぐために、sameSite のようなオプションで Cookie を使用します。

4

1 に答える 1

0

これまでのところ、署名付き Cookie を使用することを考えています。処理のオーバーヘッドが少なく、特定のことを行います。ネストされた json 形式のデータは必ずしも必要ではありません。また、API やその他の承認ではなく、Web サーバーでのユーザーの認証にのみ使用しています。公開/秘密の非対称キーの検証は必要ありません。

cookie-parser の署名オプションを使用すると、 Cookieは次のようになります。 ここuser_id=111.base64Signature での主な問題は、トークンに有効期限がないことです。 使用すると、サーバーはこれらのリクエストを受け入れます。解決策は、トークン自体にタイムスタンプを追加することです。したがって、ペイロードはおそらく json に変換され、次のようになります。

{
   userId: 111,
   exp: 1637437857
}

およびクッキー: token='{"userId":111,"exp":1637437857}'.base64Signature. したがって、ペイロードをbase64でエンコードする場合、基本的にJWTとの唯一の違いはヘッダーですtoken=header.payload.signature。

hmac を作成する方法はノードのcrypto.createHmacものであり、express ミドルウェアと一般的な jwt ライブラリ (jsonwebtoken / express-jwt) の両方で使用されるため、パフォーマンスに関しては同じ結果が得られます (ペイロードに json 形式を使用する場合)。対称署名。

有効期限を実装することにした場合、JWT フォーマットにより、さまざまなライブラリを使用して無料の検証チェックを取得できるようになると思います(Cookie パーサー ミドルウェアには欠けているようです)。これが必要ない場合は、ソリューションで機能します。 .

于 2021-11-20T20:30:30.740 に答える