Comparing with jwt

[onemanstartup]

Hi, great gem.
I'm have just one question. How this gem architecture compared to json web tokens? And one more, when exactly a request hit the database?

[lynndylanhurley]

The security measures are listed here.

The expected token format is described here.

As far as I can tell, jwt doesn't offer any advantages over this gem's token format.

[onemanstartup]

With jwt I can check validity of token just by decrypting it, without comparing with token in database. Does devise_token_auth comparing and hitting database when you checking tokens for validity?

[lynndylanhurley]

I've made a conscious decision to compare the token with the database for each request.

The main reason is for access control. For example, if a user's account has been disabled since their last login, the only way to know would be to check against the database.

[onemanstartup]

I understand, but it is heavy constraint. For example, let's imagine chat application, when you send message you can checked access control for thread by passing user_id and check manually if this id present in thread permissions, that's way you only need read thread and insert message, but with this approach i need load user for every request. This can become issue with scaling as you have more users and requests.

[lynndylanhurley]

There are other issues as well.

1. Tokens are effectively passwords. If an attacker has your access token, they can do anything with your account. For this reason, we store tokens using bcrypt. This is how passwords are normally hashed. Once the token is hashed using bcrypt, it cannot be recovered. So to check a token's validity, we perform the following actions:

   1. search the DB for a user by their uid
   2. if the user is found, hash the token from the request
   3. compare that hash with the hash that's stored in the DB
   4. if the hashes are equal, the token is valid.

   With jwt, the encrypted token is usually included with each request (that's how it saves the trip to the DB). And it's encrypted using an algorithm that can be easily brute-forced (HMAC or something). Would you do this with your password?

2. If you're building a real-time app, you should be using a socket connection (i.e. faye). This gem won't work in that context anyway.

I would be open to de-coupling the validation system so that it can be easily overridden (using jwt or anything else). Feel free to send me a PR.

[onemanstartup]

1. Access Control is not matter of authentications, it's another issue.
2. https://github.com/Notsew/ruby_jwt support different algorithms as well as custom. So anyway if you want brute force SHA-512, good luck :)
   If attacker stole token with devise_auth_token he can do anything too and encryption doesn't help.

Thanks for answers, I'm trying wrap my head around this issues to have best from both worlds.

[lynndylanhurley]

There's a good discussion about this here if you're interested.

[onemanstartup]

We encrypt token not a password, and only we can decrypt because we have secret key. So hashing token doesn't make sense. I think :)