None of this would have happened, if the token were a traditional strong random number backed by a database on their API server. I've always disliked JWT for that reason: it keeps too much state in the untrusted client, depending solely on the strength of the cryptography to protect it, and any slip-up (like this one, or the classic alg=none, or failing to correctly using a random number with ECDSA) means the client has full control. With a strong random token, all the state is in the database in the server, and the worst the client can do is leaking the token.