10

I'm trying to secure access to my web server.

I have been implementing a JSON web token authentication where I randomly generate a secretkey and associate it with that user. The secretkey will then be used to encode the JSON web token. Then the user will use the JSON web token to access my web server.

I was also thinking of this simpler method. Is there a reason not to just randomly generate a key and associate the user with that. Then authenticate with that?

Big yellow duck
  • 101
  • 1
  • 3
  • 1
    Please look at the answer in : http://security.stackexchange.com/questions/19676/token-based-authentication-securing-the-token – snorberhuis Aug 10 '15 at 10:07

1 Answers1

8

Either way is fine, it just depends whether you want authentication to be stateless.

Advantages of JWTs:

  • Stateless.
  • Little or no database overhead.
  • Individual back-end components can validate the token in isolation, simply by knowing the secret key.

Disadvantages:

  • As authentication state is stored client-side, you cannot invalidate logins server-side.

Depending on the risk appetite of your application, this could be a big enough disadvantage for you to move all authentication logic to server-side.

Note that you could combine the two, and have the authenticated token supplied client-side validated server-side (i.e. the token inside the JWT is validated by a MAC, and the token itself is stored in a database). This protects against the situation where your session table is exposed by an attack as an attacker cannot use the session identifiers directly to hijack a session without knowing the secret key used to validate the MAC.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
  • Thanks @SilverlightFox I had the same question. For the OP, here's an article that explains the revocation downside and why if you need the ability to revoke JWT's, then you might not want JWT's at all, and just stick to opaque Bearer tokens. https://www.dinochiesa.net/?p=1388 – Ian Storm Taylor Mar 14 '16 at 21:44
  • In that last case you can also not store the session identifiers directly on the database and store, for example, a salted digest of it; as django-rest-knox does (that is not a JWT module; but the idea for crypto is the same). – ssice Jul 23 '16 at 17:06