4 ms·
It definitely was an implementation issue. The JWS spec (which is explicitly referenced in the JWT spec) states clearly under section 4.1.1: 'The JWS Signature
by jondubois 8y ago
It definitely was an implementation issue. The JWS spec (which is explicitly referenced in the JWT spec) states clearly under section 4.1.1:
'The JWS Signature value is not valid if the "alg" value does not represent a supported algorithm'
Even if you did consider it a flaw in the RFC itself, the fact that there was a flaw once-upon-a-time with a specific aspect of JWT, doesn't invalidate the whole idea of JWTs.
I don't know any major standard that was perfect from day 1. This can be said about TCP/IP (e.g. IpV4 addresses were clearly a mistake). Also, I recall that there were flaws with HTTP1 and that's why HTTP1.1 was released soon after. The WebSocket protocol also went through MANY iterations.
There are use cases were JWTs are necessary. For example, I did some work with real-time presence (to get notifications when users go online or offline); to be able to get the username from the JWT instead of the database saves a lot of database queries and the code is much cleaner since you can check synchronously instead of having to wait. Also, you don't want to waste precious CPU time doing DB queries for connections that haven't been authenticated yet.
- CiPHPerCoder 8y ago> Even if you did consider it a flaw in the RFC itself, the fact that there was a flaw once-upon-a-time with a specific aspect of JWT, doesn't invalidate the whole idea of JWTs. The premise that went into JWTs was not invalidated. Their design was proven by multiple incidents to be error-prone, so I sought to replace JWTs. The result? https://paseto.io https://paseto.io