[WIP] feat(users): Initial server-side Token Authorization

[mleanos]

Initial implementation of Token based authentication on the server-side.

Adds tokenAuth settings to default env config
Adds jsonwebtoken library to project
Adds authorization configuration to config/lib

Authorization middleware

Adds the authorization.authorize to the Express middleware

Verify User data Token

Updated Token payload to just store the user._id rather than the whole
User object.

Adds an extra verification for the Token stored with the User data.

User model Auth field

Adds the auth field to the User model

auth.token
auth.expires

Login & Signup Token creation

Modified signup & signin server-side API methods to generate a signed
JWT, and store it with the User data.

[mleanos]

This is still a work in progress, but I wanted to get it out there. Figured it would be easier to track & get feedback this way.

With these changes, the application provides Token Auth capabilities to the authorization & authentication processes. If the the incoming request doesn't provide the Authorization header, then the application will fallback to Session based authorization.

I'm not sure if we'd even want Session based auth & Token-based Auth to co-exist, but it is an interesting concept :)

Any thoughts, critiques, or concerns?

[trainerbill]

@mleanos @ilanbiala @codydaig

Any thoughts on using this library for the frontend implementation of JWT?

https://github.com/auth0/angular-jwt

We would have to account for:

https://github.com/auth0/angular-jwt#not-sending-the-jwt-for-template-requests

On the server side since we are using passport would it make sense to use the JWT module?

https://www.npmjs.com/package/passport-jwt

Then you only secure the routes that you want instead of securing every route with app.use in the express middleware?

I was thinking of having a user/auth route that gets the JWT token and store it locally, possibly with the module above, then using the passport module on the routes?

Also I am not sure why we are storing the JWT Token with the user model. Isn't the point of JWT to require the token or re request one?

[trainerbill]

Why are you putting the expiration here? Would it be best to just decode the token and if the expiration date is passed then they have to login again to get a new token? I can't think of a reason to have a token and expiration here. I would just resolve the token.

[mleanos]

This method is creating a new signed Token. I use the user._id & expiration as the payload for generating the token; the expiration is beneficial since it is always going to be a unique value, thus it acts as a dynamic property for making the Token more secure.

[trainerbill]

#1163

[mleanos]

Closing this in favor of #1300