I am a cloud application architect with 10 years' experience in software development in several languages, including Perl, Java and C#. I'm an Irishman living in Calgary, Canada. GitHub on @cubikca.
Location
Calgary, Canada
Education
BSc. Computing and Info Systems, Athabasca University
I guess it would help to look at what you are actually trying to prevent. In my case, I'm interested in ensuring that an application user who accesses the application on a public terminal is not exposing their credentials to the next terminal user. The terminal user may: have access to your browser session if you forgot to close the browser; have access to your cookies; have access to your local storage. As you can see, all of these locations are potentially readable by another user of the terminal. A JWT is transferrable (though it does expire), so the next terminal user has the lifetime of the JWT to use it maliciously.
The description above is what I meant when I said "insecure". You cannot prevent another user from reading these storage locations. Therefore, you need to encrypt any sensitive data that goes in there, including your JWT. At some point though, you can only obfuscate it, because you'll have to put the encryption key somewhere on the client side too.
One method I've used to guard against the transferabiliity of JWTs is to include an HMAC signature and nonce with each request. That way, each request can only be used once and the JWT is not immediately useful to someone who intercepts it. This gets into more advanced cryptography though, and is maybe more than you need to worry about for most applications.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I guess it would help to look at what you are actually trying to prevent. In my case, I'm interested in ensuring that an application user who accesses the application on a public terminal is not exposing their credentials to the next terminal user. The terminal user may: have access to your browser session if you forgot to close the browser; have access to your cookies; have access to your local storage. As you can see, all of these locations are potentially readable by another user of the terminal. A JWT is transferrable (though it does expire), so the next terminal user has the lifetime of the JWT to use it maliciously.
The description above is what I meant when I said "insecure". You cannot prevent another user from reading these storage locations. Therefore, you need to encrypt any sensitive data that goes in there, including your JWT. At some point though, you can only obfuscate it, because you'll have to put the encryption key somewhere on the client side too.
One method I've used to guard against the transferabiliity of JWTs is to include an HMAC signature and nonce with each request. That way, each request can only be used once and the JWT is not immediately useful to someone who intercepts it. This gets into more advanced cryptography though, and is maybe more than you need to worry about for most applications.