Return to Answer

2. Generate your token using SecureRandom.hex. Or use the gem sysrandom.

   Apparently SecureRandom is not that secure. Still, there's a trade-off here: pick something from standard lib or pick a little known gem maintained by someone. For a well-informed decision I suggest reading the sysrandom's README and the blog post How to Generate Secure Random Numbers in Various Programming Languages.

3. Find the user record using the user's ID, email or some other attribute. Then, compare that user's token with the request's token with Devise.secure_compare(user.auth_token, params[:auth_token]. If you are on Rails 4.2.1+ you can also use ActiveSupport::SecurityUtils.secure_compare.

2. Generate your token with:

• SecureRandom.hex only if you are on Ruby 2.5+.
• The gem sysrandom if you are on an older Ruby.

For an explanation on why this is necessary, I suggest reading the sysrandom's README and the blog post How to Generate Secure Random Numbers in Various Programming Languages.

3. Find the user record using the user's ID, email or some other attribute. Then, compare that user's token with the request's token with Devise.secure_compare(user.auth_token, params[:auth_token]. If you are on Rails 4.2.1+ you can also use ActiveSupport::SecurityUtils.secure_compare.

2. Generate your token using SecureRandom.hex. Or use the gem sysrandom.

   Apparently SecureRandom is not that secure. Still, there's a trade-off here: pick something from standard lib or pick a little known gem maintained by someone. For a well-informed decision I suggest reading the sysrandom's README and the blog post How to Generate Secure Random Numbers in Various Programming Languages.

3. Find the user record using the user's ID, email or some other attribute. Then, compare that user's token with the request's token with Devise.secure_compare(user.auth_token, params[:auth_token].

2. Generate your token using SecureRandom.hex. Or use the gem sysrandom.

   Apparently SecureRandom is not that secure. Still, there's a trade-off here: pick something from standard lib or pick a little known gem maintained by someone. For a well-informed decision I suggest reading the sysrandom's README and the blog post How to Generate Secure Random Numbers in Various Programming Languages.

3. Find the user record using the user's ID, email or some other attribute. Then, compare that user's token with the request's token with Devise.secure_compare(user.auth_token, params[:auth_token]. If you are on Rails 4.2.1+ you can also use ActiveSupport::SecurityUtils.secure_compare.

5. There should be some kind of mechanism that causes the token to expire. When implementing this mechanism take into account the trade-off between UX and security.

   Google expires a token if it has not been used for six months.

   Facebook expires a token if it has not been used for two months:

   Native mobile apps using Facebook's SDKs will get long-lived access tokens, good for about 60 days. These tokens will be refreshed once per day when the person using your app makes a request to Facebook's servers. If no requests are made, the token will expire after about 60 days and the person will have to go through the login flow again to get a new token.

6. Upgrade to Rails 4 to use its encrypted cookie store. If you can't, then encrypt the cookie store yourself, like suggested here. There would absolutely be no problem in storing an authentication token in an encrypted cookie store.

5. There should be some kind of mechanism that causes the token to expire. When implementing this mechanism take into account the trade-off between UX and security.

   Google expires a token if it has not been used for six months.

   Facebook expires a token if it has not been used for two months:

   Native mobile apps using Facebook's SDKs will get long-lived access tokens, good for about 60 days. These tokens will be refreshed once per day when the person using your app makes a request to Facebook's servers. If no requests are made, the token will expire after about 60 days and the person will have to go through the login flow again to get a new token.

6. Upgrade to Rails 4 to use its encrypted cookie store. If you can't, then encrypt the cookie store yourself, like suggested here. There would absolutely be no problem in storing an authentication token in an encrypted cookie store.