CODEWITHSUNDEEP
javascriptjsonvalidationauthenticationjwt
BeniRose
BeniRose

Reputation: 412

JSON Web Tokens (JWT) - Validate Client

I've been investigating JWT and I'm very interested in using it. I like that it doesn't require state checks on the server, due to the digital signature and payload contents.

The thing I'm having a hard time is validating the client. I understand that the signature allows the server to say "yes I issued this token, it is valid", but I don't totally understand how the server can verify the client is who it says it is.

Digital signature makes sense from the server side, but the client can't sign anything to verify who it is because browsers can't keep secrets. This is the one part I haven't been able to wrap my head around. If the browser can't keep the secret, how can it add data to the token (like a nonce, or information about the resource it's requesting) to be included in the signature, similar to how oAuth 1.0 works.

Is this not supported? Are there other way to validate the browser is who it says it is? What if my client has a security hole that leaks tokens? If the client isn't validated, couldn't anyone use those tokens? I don't think "short expiration times" is a good solution to that problem.

Can someone help me wrap my head around this part of JWT?

Upvotes: 2

Views: 1610

Answers (2)

Rob
Rob

Reputation: 1860

To add on to what Tim B said, I have used tokens where the secret key has the browser AND ip appended to it like so: (PHP Example)

$secret_key = 'kajsdfkljk' . $_SERVER['REMOTE_ADDR'] . $_SERVER['HTTP_USER_AGENT'];

That does seem to work, however, if you're bouncing around from network to network, then you would have to login each time, in which case you could just use the user agent and not the ip.

Another thing to note here is that if there was a leak of some sort, you could always change the secret key, in which all tokens issued from your server would no longer be valid.

Also, without using https connections, tokens can be very dangerous to use for authentication.

Upvotes: 3

Tim B
Tim B

Reputation: 1877

Verifying the client isn't compromised isn't really possible, as it could definitely leak a token. Token expiration helps mitigate a leaked token being dangerous for too long, but as you mentioned isn't a fool proof solution. You could do something use the requesting user's current IP address as part of the signing key to help mitigate against a leaked token being used elsewhere. It could still be used via XSS locally, but not as easily used by phishers.

My understanding is that the client wouldn't add information to the token, it would simply pass it beside the additional info. Separate POST vars -- a token to "verify" identity, the other vars to define additional parameters.

Upvotes: 2

Related Questions