Is it secure to decode the jwt token on client side ?

[a45b]

Query 1:

You decode the jwt-token on client-side on the below example
https://github.com/auth0/angularjs-jwt-authentication-tutorial
Because to decode i need the secret-key and if I put the secret-key on client side it definitely not secure.

Query 2:

Also I am try to copy the jwt-token and open the url on another browser and pasted the jwt-token and wallah ...I got authentication. So if someone can get to my browser and copy that token s/he will get the access.

[dschenkelman]

Hey @iamkdev,

I'll try to answer your questions separately:

1. What you said above is partially true. Having the secret on the client side is not secure, but as you can see in this line to decode the JWT you don't need the secret ket, you only need the JWT itself. Note that decoding means decoding from Base64, there's no secret ket involved in that process. On the other hand, verifying a JWT would require a secret key because it would involve a cryptographic signature operation.
   To sum up, decoding does not need the secret (remember decoding is just interpreting base64) and verifying/signing is does require it.
2. Yes. That happens with every authentication mechanism that stores something in your browser, e.g. a cookie that you use to authenticate with Gmail. There's an interesting discussion going on here with lots of nice ideas around this topic. Feel free to join :)

[a45b]

Thanks @dschenkelman
Token-base authentication is a wonderful and great alternative to session base authentication. I am really excited towards it.

[dschenkelman]

Great to hear that :). Closing this if it's OK with you.

[devcenter]

For query 2: one of the way you can prevent this is by adding device id (mac address, ip address or other identifier specific to the session) in the payload, then verify it on the server side

[a45b]

If I use mac address, ip address then it will be difficult to use from proxy or vpn...?

[nawlbergs]

Token can be read without any secrets or keys... its not encrypted... so don't put someones ip address in it... or anything that you don't want to get into someone else's hands. If someone tries to change the data in the token, it will not be verified correctly on server.... so you can just treat it as a "read-only" public identifier.

[bikegriffith]

If you need to decode client-side without a server-side verification, you should be using RSA for your JWT ... sign it with the private key and verify it with the public key.

[FullStackForger]

It s an old topic but just in case someone stumbles upon this conversation it is important to mention SSL. If you are sending any credentials or sensitive information back to the server always do so over HTTPS.

[dimaxweb]

L

[Xample]

The asymmetric keys work as follow: the private held by "A" can encrypt something, anyone having the public key can make sure this "something" was encrypted by "A". No one, having a public key can easily forge a cypher / token, to pretends "A" encrypted it.

Therefore, in short: yes you can decrypt the JWT token on the client side, you will know the content but it will be useless… at first, because this is your own content (you can steal yourself) but moreover if you try to modify that one, you will not be able to sign it so that the server will accept it (because remember you do have the public key, not the private key).

For info, if you were encrypting something with a public key, you would only ensure this one to be decryptable by the one having the private key (useless as well in this case, but just to share).

For symmetric keys (same key on the server and client side) it's not the same purpose: