2016-12-09 3 views
2

私はシングルページアプリケーションを開始しています.Javascript Webトークンを使用してクライアント側(JSクライアントとサーバーAPI)を認証しています。シングルページアプリケーションJWT、トークンリフレッシュと長寿命トークン

私のアプリでは、ユーザーは認証情報(アプリ認証、Facebook、Google)を提供し、サーバーはユーザーの存在をチェックしてトークンを返します。

クライアントJSは、Server APIを使用するために各リクエストにトークンを追加します。

トークンが発行されると、有効期限と最大リフレッシュ時間があります。トークンの有効期限が短く、リフレッシュ時間が「良い」の場合、トークンをリフレッシュするタイミングを知る必要があります。私が今までに見つけた最良の方法は、トークンが期限切れになっている(5分前に)ときにクライアントをチェックして、リフレッシュ要求を発行することです。それから私は新しいトークンを取得します。これは、最大リフレッシュ時間に達するまで実行できます。次に、ユーザーは再認証する必要があります。

私が見てきた別のアプローチ、トークンがほとんどであるか、単に期限が切れている場合は、サーバー上で、それは自動リフレッシュされますし、クライアントに返されていることである(トークン変化を検出し、それを保存するために持っている)

しかし...これとの違いは何ですか?単一のトークンを持っているのは "良い"セシオン時間ですか?

1つの長いトークンを持つよりも、何回も認証することなく更新できる短い存続トークンを持っていますか?

答えて

0

短命トークンを使用する主な理由は、敵対者がセッション資格情報(この場合はトークン)を盗み、犠牲者のセッションで悪意を持って行動した場合、session hijackingを守ることです。トークンの存続期間が短くなればなるほど、攻撃者は計画した悪意のある活動を実行する時間が短くなります。

+0

トークンが自動リフレッシュされると、1トークンを盗むということは、最大リフレッシュ時間まで自動リフレッシュされていることを意味します。したがって、長くても同じですか? – vegetable

+1

オートリフレッシュとは、どういう意味ですか?標準モデルでは、元のアクセストークンを使用してリフレッシュトークンを送信します。このトークンは、単一の新しいトークンに交換することができます。それはすべての要求と共に送られるべきではありません。ユーザーが期限切れのアクセストークンで接続しようとすると、サーバーはリフレッシュトークンを要求します(またはクライアントは、トークンが期限切れであることを知っているので、リフレッシュ要求を行います)。クライアントにそれがない場合は、ログインするように求められます。ログインすると、既存のすべてのリフレッシュトークンとアクセストークンが無効になり、サーバーから送信された新しいペアに置き換えられます。 –

+1

リフレッシュトークンを使用すると、現存のすべてのアクセストークン、*および*そのリフレッシュトークンが無効になることが重要です。したがって、リフレッシュトークンが盗まれ、攻撃者がそれを使用して新しいリフレッシュトークンとアクセストークンを取得した場合、そのトークンが無効になったため、次のリクエストでログインするように求められます。そのログインは、上記のように、新しいトークンペアを作成し、攻撃者が得たトークンペアを無効にします。 –