1

I'm using jwt-simple to create an api key. Basically what it does is encode(secret+data) and sends it attaching with the request. I'm aware that the server will decode(encode(secret+data)) and verify that it is a valid request. Sample code found in jwt-simple documentation:

var jwt = require('jwt-simple');
var payload = { foo: 'bar' };
var secret = 'xxx';

// encode 
var token = jwt.encode(payload, secret);

// decode 
var decoded = jwt.decode(token, secret);
console.log(decoded); //=> { foo: 'bar' }

My questions are:

  • Wouldn't someone be able to access the API if they know the token generated by encode(data+key)? Is that why I should use HTTPS over HTTP?
  • I think I need to store the secret of each user on the server as well, since it will be needed to decode. Where should I store it if I'm not correct?
  • How would I send multiple API requests? Is there a better way other than sending the API key for every request?

Thanks in advance.

SherylHohman
  • 16,580
  • 17
  • 88
  • 94
Prashant Ghimire
  • 4,890
  • 3
  • 35
  • 46
  • 1
    You are not supposed to send the key to anyone. You are only sending the generated token (from which you cannot guess the key) and you get that token back. You then use your key to verify that this token was generated by you using this key and was not tampered with. Also you need one key per issuer and not per user. – masimplo Oct 05 '15 at 20:21

1 Answers1

1

See this post regarding your confusion with the secret: Can anybody decode a JSON Web Token (JWT) without a secret key?

As for your questions:

  1. Yes, everybody who somehow manages to get a valid token can access your API. So if someone knows the secret key you use for signing your tokens and can create a valid payload, he can use the API. But the usual flow would be: a user logs in, you check the password, if it's the right password you give him a valid token. If someone grabs that token from that users computer there is not much you can do. But you can make tokens expire so if someone steals one it is not valid for very long.

  2. You can sign your tokens with the same application wide secret but you would use some unique user specific payload so that every user gets a different token.

  3. In a simple solution you would just send the token with every call you make to the API (besides login and sign-up). There are other solutions with establishing sessions but I think they are a bit more difficult to implement.

Community
  • 1
  • 1
June
  • 385
  • 5
  • 14