2017-06-09 6 views
1

私はJWT Webトークンの有効期限を短く設定しようとしています。私が問題に遭遇しているのは、クライアントが異なるタイムゾーンのサーバー(EST)にいる場合です。現在、作業コードは次のとおりです。JWT setサーバーのタイムゾーンのための設定のセキュリティ

Map<String, Object> header = new HashMap<>(); 
header.put("typ", Header.JWT_TYPE); 
long now = Instant.now().getMillis(); 
String compactJws = Jwts.builder() 
     .setHeader(header) 
     .claim("email", email) 
     .claim("password", password) 
     .claim("reg_id", reg_id) 
     .claim("deviceId", deviceId) 
     .claim("gsf", returnGSF()) 
     .claim("imei", returnIMEI()) 
     .claim("serial", Build.SERIAL) 
     .claim("version", String.valueOf(version)) 
     .claim("language", language) 
     .setIssuedAt(new Date(now)) 
     .setExpiration(new Date(now + 60000)) 
     .signWith(SignatureAlgorithm.HS256, settings.getString("keychain", "password")) 
     .compact(); 

60秒は余裕があります。私はすべての異なる日付/書式のオブジェクトの変形で私の髪を引っ張っています。どのようにデバイスの場所に関係なく、米国東部時間の日付オブジェクトを取得するには?

答えて

0

JWTタイムスタンプは常にUTCベースであるため、タイムゾーンは問題ではありません。

クライアントとサーバーのクロックが同期していない可能性があります。 60秒はクロックスキューに対する許容度があまりありません。他のプロトコルははるかに大きな分散を使用します。たとえば、Kerberosでは、クロック間で5分のデルタがデフォルトになります。

+0

サーバーは、ttlが時間以上の場合、トークンが期限切れと判断します。異なるタイムゾーンをシミュレートするためにクライアントデバイスの時間をEastern以外に変更すると、すぐにトークンが返されます –

+0

'Instant'はUTCベースです。 'Date'もそうです。 JWTも同様です。チェーン内の何もクライアントタイムゾーンの影響を受けないはずです。あなたのコードのどこかに何か他のことが起こっているはずです。 –

+0

十分な深さまで掘り下げれば、その日付オブジェクトに対して 'getTime'を呼び出すだけでJWTSの' setIssuedAt'さえできますので、ローカルタイムゾーンはどこにも適用されません。 –

関連する問題