Is this API Token scheme secure enough

Question

I am designing a REST Api for a mobile application and have some worries over properly securing access to accounts.

I am writing the API server in nodeJS and it will primarily be consumed by a mobile client (although a web client may be added in the future)

There are 2 main side aspects I wish to incorporate in the auth process:

1. Users ID is encoded in the token (to reduce stress on DB)
2. User can have only 1 valid token at any one time (login nulls any previous token)

Here is my initial design (all endpoints are over SSL):

Login

1. User POST's her username & password to '/login'
2. Server verifies users exists and the password matches the bcrypt hash in the Db
3. Server generates a uuid v4 for the user and stores this in Reds with the users ID as the key
4. The users uuid and user ID are then encoded in a Json Web Token with an expiration time of 1 week
5. The JWT is then sent back to the users as their authentication Token

Protected Route

1. User sends GET request '/users/me' withe her token set as Authorization: Bearer header
2. Server verifies the JWT and sends appropriate error responses if verification fails
3. Server then queries the Redis store and verifies the uuid stored for the user matches the uuid encoded in the JWT
4. If uuids match the users id is set to req.user and the request is processed, if not then error message is sent back

Does this look like a good authentication strategy or am I way off?

Answer 1

I find two possible flaws.

UUIDs in general do not guarantee to be cryptographic random. Depending on implementation it may be possible to give a qualified guess about what other UUIDs have been generated by a generator, given some of the output. You need to use a suitable length of output from a cryptographic random number generator as session token.

Whenever you extend to a web client you need to secure against cross site request forgery, that is, any request that change data on the server needs to have a token that is not a cookie as part of the request, otherwise the request can come from another open web site on the users computer.

Another thing, if you want to reduce stress on the DB, you can store session information in process memory in Node. You only need the database for things that has to persist through a crash.