CODEWITHSUNDEEP
securityjwttoken
Ivan
Ivan

Reputation: 55

JWT advantages over simple randomly-generated tokens in database?

Let's say I have a typical CRUD API for a web application. I need to authorize users by a token, check user roles, etc.

Is there any reason why I should consider JWT over storing a randomly-generated token in a table like tokens(token, refresh_token, expiration_date)?

In my opinion, JWT is adding more complexity here:

  1. Additional code to handle encoding/decoding

  2. Need to store JWT secrets and keys

  3. Token revocation problem

I have to hit a database to check user roles(although I can include them in a payload, there's also other stuff that I should check in my application), so no advantages here. The only benefit I can see here is that I can check token expiration data without hitting a database.

At the same time storing a randomly-generated token in a database is a dead-simple solution.

Am I missing something?

Upvotes: 4

Views: 1449

Answers (2)

Gabor Lengyel
Gabor Lengyel

Reputation: 15570

JWTs are often misunderstood. The main benefit they provide is statelessness. If you go to your database to query privileges upon each request anyway, that is pretty much lost, if not from a theoretical but from a practical point of view.

They are typically not stored in http-only cookies, which makes them vulnerable to XSS, but at the same time allows Javascript clients to read the payload (eg. who is logged in, what privileges they have and so on). Not being stored in cookies also allows them to be sent to different origins, which is pretty much the only reason they should not be stored in a http-only cookie (if and only if you understand and accept the risks of this).

JWTs are in no way better or magically more secure than plain old random session tokens - quite the opposite in most cases, especially that it is often overlooked that as opposed to server-side sessions, JWT payload is plaintext. It is protected against tampering by message authentication, but not protected against the user having a look, which sometimes might become an issue.

If you don't need the features above (statelessness, access from javascript), you should just not have the additional complexity of a JWT, you just need a plain old session then.

Upvotes: 6

ameet chaubal
ameet chaubal

Reputation: 1540

First thing you need to consider is who will generate the token. In case of JWT, a valid OAUTH provider will generate the token. The benefits are as follows,

  1. you can validate the legitimacy of the token, which will include checks for following,

    a. audience

    b. expiry

    c. issued at

    d. not before date

    e. issuer

    1. you can check the issuer based on just the public key which would avoid a network trip to another remote server such as database.
    2. you can inject any payload which can include a userinfo, email, role or any custom attributes.
    3. for a standard OAUTH JWT, you can test using common providers such as 'Okta'. As opposed to your custom generator, where you will have to provide a user a mechanism to retrieve such a token.

as far as the code to check, the JWT is quite straightforward with 3 parts separated by a "period". But there are libraries in java and other languages which can do the parsing for you - com.auth0, specifically jwt and rsa which will let you do the parsing and verification.

your code will be compliant and easily portable to another provider.

Upvotes: 0

Related Questions