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?

3 Answers 3


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.

  • 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.
    – mnj
    Commented Aug 20, 2018 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.
    – Irfan434
    Commented Aug 20, 2018 at 16:32
  • Ok, good point.
    – mnj
    Commented Aug 20, 2018 at 18:09

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.


  • 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
    – mnj
    Commented Aug 20, 2018 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.
    – Irfan434
    Commented Aug 20, 2018 at 16:36
  • So basically the only advantage of JWT over user/pass is expiry
    – mnj
    Commented Aug 20, 2018 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.)
    – Irfan434
    Commented Aug 20, 2018 at 19:19
  • 1
    @Loreno The password could be used to access user account where tokens are managed among other operations.
    – elsadek
    Commented Aug 20, 2018 at 19:21

Another advantage of session tokens is that each client gets a unique one, and the user can see what sessions are active and what they're doing. This means they can do things like end a mobile app's session without needing to end all the other sessions. This requires the ability to revoke tokens, of course (not necessarily possible with JWTs, but you can pair a very-short-lived JWT with a long-lived refresh token, and revoke the latter).

However, the main advantage of JWTs in particular over other kinds of session token (or credentials, when the site the user is using is the same one they authenticate to, i.e. not using third-party SSO) is performance, not security. JWTs let the server avoid knowing anything about the user's session. This is especially valuable for distributed computing; no need to tie a user to a specific server instance (you can load balance freely) or distribute/synchronize a user's session data across all server instances. Authentication (with username/password) is also somewhat expensive if done correctly - you want to use an intentionally-slow hash function - so you really don't want to be doing it on every request, even aside from the DB query.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .