3 ms·
This is not accounting for reconnect scenarios. With sessionId, if the user loses the connection and reconnects, there will need to be another DB lookup to veri
by jondubois 8y ago
This is not accounting for reconnect scenarios. With sessionId, if the user loses the connection and reconnects, there will need to be another DB lookup to verify that the sessionId is valid. This is not the case with JWT. The validity of the JWT can be checked without any DB lookups.
Also, this is a security consideration because a malicious user could intentionally send fake sessionIds to make us DoS our database. With JWT, verification of the signature only uses CPU on the workers which are easier to scale.
- throwawaymath 8y agoWhy wouldn’t you rate limit connections? That is something you should be doing anyway, and it neatly resolves the denial of service problem.
- ynniv 8y agoYou can sign session ids to prevent DoS, and you can cache session ids to avoid database lookups, but you can't detect forged or stolen JWT tokens.
- nmgsd 8y agoYou can't forge a JWT without stealing the private key of the valid JWT signer. You can steal a JWT token the same way you can steal a session token.
- deleted 8y ago[deleted]