2

JWT tokens seem like a very good idea. You can send a request to some API without using your username/password secret pair.

Still, I don't fully understand the benefits that it gives. I have two questions:

  1. To get the token, user still needs to send his credentials to some server that issues these tokens. Isn't it a weak point of all this?
  2. If attacker steals the token while it's being transferred, he can use it to pretend he is someone else. The only difference between this and using user/password combination is that JWT tokens get expired after some period of time, so attacker doesn't have much time to do his thing.

Is my understanding correct? What am I missing? What are real advantages of using JWT vs user/password?

7

Suppose there are 2 servers: TRUSTED (e.g Google) and UNTRUSTED (any site that allows 'Sign in with Google').

I don't want to send my TRUSTED username and password to UNTRUSTED. I also don't want to make a separate username and password for UNTRUSTED.

So instead I get TRUSTED to authenticate me, and send a signed JWT containing my identity to UNTRUSTED to prove who I am. UNTRUSTED can check if the JWT is really from TRUSTED by verifying the JWT signature using TRUSTED's public key (if the signing algorithm uses public/private keys, e.g. RS256).

JWTs can be stolen in transit, as can usernames and passwords, so this is a real risk (although, as you mentioned, JWTs will expire sooner). HTTPS will minimize the risk by encrypting data in transit.

Another major benefit of using JWTs is that verifying a signature is often faster than checking an access token against a database (because of database and storage access time).

  • I still don't really see benefits of JWT vs user/pass. If I send my token to UNTRUSTED, UNTRUSTED still can use this token without my knowledge. About access time - when I call some API, usually it will access database anyway, because that's what most APIs do. – Loreno Aug 20 '18 at 15:59
  • 1
    @Loreno You say that UNTRUSTED can use the JWT without your knowledge. Well, the JWT will contain an "aud" (audience) claim that identifies the recipients that the JWT is intended for. If UNTRUSTED1 sends a JWT to UNTRUSTED2, UNTRUSTED2 will see that the "aud" claim is wrong, and reject the request. – Ahmad Aug 20 '18 at 16:32
  • Ok, good point. – Loreno Aug 20 '18 at 18:09
2

You are missing a point; in the most API architectures the server doesn't hold a session of the different calls made by the same client, this is described as stateless server, that is why the client must provide authentication token on each request and here where JWT comes handy.

... the main reason why is better to use a token instead of account_id/password is to avoid frequent circulation of the password over the wire. Remember The stateless nature of API, it makes the client to provide credentials on each request.

(https://security.stackexchange.com/a/191200/21144)

  • I understand very well the stateless nature of web APIs. What's the difference between frequent circulation of user/password vs frequent circulation of tokens? If some API uses tokens to authenticate user, then stealing of the token is as dangerous as stealing user/password – Loreno Aug 20 '18 at 16:01
  • @Loreno You already recognised that JWTs expire sooner, so stealing a password is more dangerous than stealing a JWT. A password can also be used to obtain more JWTs. – Ahmad Aug 20 '18 at 16:36
  • So basically the only advantage of JWT over user/pass is expiry – Loreno Aug 20 '18 at 18:08
  • 1
    @Loreno Another advantage is the claims in a JWT can contain lots of information (e.g. authorization scope, user info, etc.) – Ahmad Aug 20 '18 at 19:19
  • @Loreno The password could be used to access user account where tokens are managed among other operations. – elsadek Aug 20 '18 at 19:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.