yjs / y-redis

Alternative backend for y-websocket
GNU Affero General Public License v3.0
176 stars 39 forks source link

JWT exp should be unix timestamp according to RFC 7519 #25

Open Coniface opened 4 months ago

Coniface commented 4 months ago

Checklist

Describe the bug I believe the current implementation on exp claim is not conform to RFC 7519

[The "exp" (expiration time)] value MUST be a number containing a NumericDate value.

Also, the NumericDate value is described here

NumericDate A JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds.

To Reproduce Steps to reproduce the behavior:

  1. Generate a JWT using the RFC implementation of exp
  2. Try to connect to the y-redis server
  3. See error
Failed to auth to endpoint /y-redis-demo-app Error: Expired JWT
    at Module.verifyJwt (file:///Users/naydenoff/dev/y-red-dve/y-redis/node_modules/lib0/crypto/jwt.js:51:11)
    at async registerYWebsocketServer.redisPrefix.redisPrefix (file:///Users/naydenoff/dev/y-red-dve/y-redis/src/server.js:57:38)
    at async upgrade (file:///Users/naydenoff/dev/y-red-dve/y-redis/src/ws.js:117:50)

Expected behavior The exp field should be unix timestamp to match RFC 7519.

Screenshots A screenshot showing the current expiration date being 4/25/56333 image

A screenshot showing the expected expiration date being 5/12/2024 image

(Yes, the token is meant to be valid 5s for test purposes in this screenshot)

Environment Information

Additional context I understand that it does work if I generate a token with the expected exp of y-redis. But as it is supposed to integrate with the user's server, I believe it's best if we respect the RFC so that anyone can just use the project without surprises.