Node.js-是否需要解码身份验证令牌？

Question

I am using a combination of Node.js and Passportjs on the server-side, and Emberjs on the client side for an app. My current Authentication strategy is to use Passport-Local to authenticate users with normal email/password combinations as standard, and then hook in a session creation mechanism to generate an Authentication Token, which is saved into a separate table, and passed back to the user for use in any further protected routes. (passed in the REST header).

Creation of the token is fine, i'm doing that without issue, however i'm struggling to work out if I need an extra step.

Currently, I generate the token with node-jwt-simple by using a random node-uuid pass as the payload, and the users UID (another node-uuid ) as the secret. I then save this to a $.cookie on the clientside, and to a table on the serverside, along with a creation date.

Obviously, one of the steps in node-jwt-simple is to encode the token. There is also a decode function provided. My question is, do I need to decode the token into something when I am doing my auth checking, or is simply checking the user's session cookie (REST header) for a match against the token in the database sufficient? I wouldn't want to go to all the effort of having generated a token, only to then miss an important step, but i'm not seeing how I could decode it into anything that would provide any additional useful security.

UPDATE:

I think I worked this out last night:

The solution seems to be to use the User's UID as the payload for JWT, with a static string as the secret (taken from something like a server environment variable or similar), and then only store the encoded token in the database. Pass the token back to the client for re-auth, then when the client attempts to access a protected route, they must pass their UID along with the encoded token to the server, which is then decoded, and the decoded payload compared to the UID that has been passed. If they match, the auth is successful, otherwise the token is destroyed and the user has to log in again. By doing this, it makes the store of tokens effectively useless without knowing either the Secret key, or having the User's UID, but makes the auth process more secure.

Answer 1

If you don't validate the token, you could as well create some other random data to use as a session cookie, as long as it is unique and cannot be guessed by clients.

But as you already made a lot of effort, you could encode something useful in the token which tells you how long it is valid, eg an exp field, so you don't have to read from the database.

I'm not sure if I fully understand your JWT, but the problem I see is that you need information to decode the token which is probably not at your hand. So you have to do a search in your database.

I think it would be sufficient to use some random session key, eg following function:

var crypto = require('crypto');

/**
 * Create random bytes and encode base64url.
 * @param {int} [lengthInBytes=40] the size of the raw token in bytes
 *        (will be longer since base64url-encoded)
 * @param {function} callback node-style callback-function;
 *        data-parameter is a string w/ a shortened (no trailing ==)
 *        base64url-encoded string of the generated bytes.
 */
exports.createRandomToken = function createRandomToken(lengthInBytes, callback) {
    if (typeof lengthInBytes === 'function') {
        callback = lengthInBytes;
        lengthInBytes = 40;
    }
    crypto.randomBytes(lengthInBytes, function (ex, buf) {
        if (ex) {
            callback(ex);
            return;
        }
        callback(null, buf.toString('base64')
                          .replace(/\//g, '_')
                          .replace(/\+/g, '-')
                          .replace(/=/g, ''));
    });
};

Answer 2

1. Set expire time of the token as small as possible(5 min, 30 min, nor months neither years).
2. Use refresh token to get a new token and update refresh token every time you update old token (and when user is logged in, no doubt)
3. Do not store passwords, credit card numbers and any confidential informations in the token ( I'm shure, you know it :) )
4. Store all necessary information for checking privileges ( or checking ip, for example ). It is good for REST API and horizontal scaling.