1

JSON Web Tokens について読んでいて、いくつかの疑問が頭に浮かびました。セッションベースのアプローチから JWT に移行する方法について、多くの主張を読みました。私は、UI とモバイル用の API を公開する Node JS バックエンドの観点から、より多くのことを考えています。

主張: JWT では、http 要求ごとにキー値データ ストアと通信する必要はありません。

質問 1 : すべてのユーザーに対して単一の秘密鍵を持つことはできません (秘密鍵が 1 つしかない場合のセキュリティ リスクは何ですか?)。とにかくDBが必要です。

クレーム: JWT はすべてのリクエストでトークンを送信します。したがって、セッションに「name,email」などのデータを保存する必要はなく、トークン自体に存在できます。

質問 2 : ペイロードはリクエストごとに送信され、データも含まれているため、ペイロードのサイズは大きくなりませんか?

Claim : Web UI Auth だけでなく、モバイル認証にも同じ方法を使用できます。

質問 3 : サーバーはトークンを復号化してサーバーと通信する必要があるため、Web UI のオーバーヘッドではありませんか?

Claim : JS にトークンを渡し、トークンを sessionStorage または localStorage に保存します。

質問 4 : sessionStorage には「httpOnly」という概念がないため、セキュリティ上の懸念はありませんか? また、Chrome プラグインは、トークンを取得してログインすることでセキュリティを回避できますか?

最後に、CRSF の問題を除けば、UI と Mobile Auth の間でコードを共有し、CSRF にメリットをもたらしますが、現在のセッション ベースのメカニズムよりも大きなメリットはありません。私の考えは正しいですか？

また、従来のセッションベースのシステムと比較した場合の JWT の欠点は何ですか?

4

1 に答える 1

0

質問1

はい、ユーザーごとに一意に JWT に署名したい場合は、それらのキーをデータベースに保存する必要があります

また、トークンが取り消された場合、トークンが有効であってもそのリクエストを拒否する必要があるため、トークンをdbに保存する必要があります

ただし、ここで注目すべき点は、このトークン ベースの認証はアプリだけでなくすべてのクライアントに役立つため、Api を書き換える必要がないことです。

JWT は、トークン ベースの認証におけるトークンの 1 つの形式です。

質問2

はい、JWT に少量の詳細を追加しても、ペイロードは簡単に 700 から 1000 文字に達する可能性があります

ただし、認証されたユーザーに関する明確な情報をヒットせずに取得するのに役立ちます。ここでの提案は、非常に最小限にして残りを db に保存し、必要なときに使用することです。

質問3

いいえ、クライアント (Webapp) がここで行う必要があるのは、各リクエストでそのトークンを保存して送信することだけです。これは、セッション Cookie を送信するのと同じです (自動です)。

質問4

はい、誰でもトークンをコピーしてアクセスできます (ただし、短時間で有効期限が切れます)。これは (セッション ハイジャック) と同じです。または、セッションが確立された後、ユーザーはクッパの残りのコンソールから Apis を直接呼び出すことができ、それでも機能します。

この場合、トークンは通常、セッションの有効期間よりも有効期間が短いため、効率的です。

JWT には真の利点があります。一番の利点は、同じ Api を任意のクライアントに公開できることです。Webapp や他のクライアント用に個別の Api を作成する必要はありません。

JWT はまだドラフトであり、仕様ではありません。慎重に使用すれば、実際の利点があります。トークン ベースの認証について検索すると、セッションよりも多くの利点が見られます。

于 2015-05-21T08:04:55.630 に答える