Secure api with express-jwt (wip) #82

dougal83 · 2017-07-13T10:20:15Z

First draft to secure api. I hope it is useful. Includes:

implemented express-jwt on server side
pertinent endpoint calls to use AuthHttp
restructured auth imports
altered loggedIn check to use tokenNotExpired
restricted cats page to logged in users (due to api change)

Have rudimentarily tested API using postman: http://imgur.com/a/srpLU.

Also not sure about (have arbitrarily returned observable boolean in place of boolean):
30: client/app/services/auth.service.ts

TODO: Address user roles

Issues: #58

jmrapp1 · 2017-07-21T21:23:46Z

Few suggestions:

You created a new "auth" module, but kept all of the services related to that module within the top services folder. The point of a module is that you're able to pick up that code and put it in another project without there being any conflicting code. For example, the shared folder contains all of the module information for the shared module. What I would suggest is for you to move the auth module and all of its services to a "auth" folder to contain the module itself. Technically, this folder should also be at the same root as the "app" folder (/clients/) because app is a module separate from auth. The shared folder should also technically be in /clients/, but that's a different issue.
I see you're using express-jwt for the JWT handling on the server-side. If you haven't heard of Passport, it's an authorization library that allows for different authorization strategies and is widely used. There is a separate module called passport-jwt that you can add to your package and it adds a JWT strategy to authorize a user and integrates directly into passport. I think this may be a safer, more scalable option that you may want to take a look at.

jmrapp1 · 2017-07-22T02:39:42Z

client/app/services/auth-guard-login.service.ts

@@ -8,7 +8,11 @@ export class AuthGuardLogin implements CanActivate {
  constructor(public auth: AuthService, private router: Router) {}

  canActivate() {
-    return this.auth.loggedIn;
+    if (this.auth.loggedIn()) {


you can shrink this: return this.auth.loggedIn();

At the time of writing while referring to angular2-jwt documentation I considered that but just left the code ready for a redirect like in the usage example. Thought that I'd let Davide see the pull request if helpful or requires changes.

It's ok, mabye just add a comment stating that a redirection would fit well in those lines.

dougal83 · 2017-07-22T13:28:04Z

Thank you for your feedback @jmrapp1 . I do need to learn how to implement the module properly. It was a rudimentary gathering of auth functionality without restructuring in mind.
With regard to passport, I'm aware of the useful features but I didn't want to deviate from the current implementation atm. I'd defer to @DavideViolante for direction, if he decides the contribution is heading in the direction he had in mind.

One thing that I've not had time to look at is restricting the API calls to user roles on the server. I guess that we'd use the token but I'm far from a reasonable understanding of express to write atm. Please feel free to make a pull request with your ideas using any part of my work.

jmrapp1 · 2017-07-22T13:54:17Z

I understand the idea to not deviate away from the MEAN stack and I suppose that's something @DavideViolante could give his opinion on, but I think that adding passport is almost trivial. We could use passport to implement the JWT strategy to authenticate users based on their JWT token or we could use your implementation. There's almost no difference there, but you kind of have to look at the bigger picture. The point of this repo is to allow other users to come in, fork it, and make their own additions or changes. With this being said we can assume that not every developer will want to use JWT, and we should allow there to be an easy way to implement their own authentication. By using your implementation it restricts the scalability of authentication. The developer is locked into the JWT auth and if they want to switch to something else they'll have to pick out any JWT related code. The reason that passport is a good option is because it allows the developer to use multiple strategies for different endpoints through the use of middleware on express routes: router.get('/account', passport.authenticate(<strategy>), userCtrl.getAccount). If the developer wants to switch to a different authentication strategy or use another authentication strategy alongside the JWT strategy (like OAuth), they can simply change the middleware.
Well I have my own branch of this repo that I'm working on for a private project and have implemented JWT tokens alongside express, with restricting roles to user groups. The user groups are really simple actually. When trying to access a route you just have to have middleware to check if the role of the user is equal to some specific role type in order to access the route

dougal83 · 2017-07-22T15:27:37Z

I will look at improving this when I have time. Seems like I'd be reinventing the wheel if someone has already made the implementation based on this project... would love to see how you've done it if you'd be happy to share. As I'm learning if you can share any good reading material I'm be grateful. Thank you for your scrutiny of my attempts thus far.

EDIT: Along with your feedback, I might look into https://github.com/MichielDeMey/express-jwt-permissions as it looks like it might fulfil the requirements.

jmrapp1 · 2017-07-24T13:56:39Z

That's an interesting repo, I'll have to look more into it but it seems like it would integrate with any JWT middleware. If I have some spare time I may work on an implementation with passport and passport-jwt, but only if it's in demand and @DavideViolante is still active with this repo. A few PRs (including yours) have been open for a few months without any comment from him, so if he is letting the repo die and not merging acceptable PRs it may not be worth my time. At that point I'd rather just create my own repo and support it.

DavideViolante · 2017-07-24T14:01:38Z

Recently I don't have enough time to reviews those PRs. I want to be sure that the PRs I receive are worth to be merged (and I also need community help on this).
I surely would like a PR about securing the APIs (like this) and/or implementing passport into the project.
When I've some time I'll look into the PRs.
This repo is absolutely not dead, I will keep it updated as much as I can.

jmrapp1 · 2017-07-26T13:39:30Z

Awesome to hear @DavideViolante :D Glad it's not dead because the repo is a great basis for people to work off of and has a lot of room for more potential. I think that this PR has a a few changes that could still be made (mentioned above), but is moving in the right direction.

dougal83 · 2017-07-26T17:04:18Z

Marked as WIP there is plenty to be improved in this PR. It's probably going to need to be broken down into smaller PRs like consolidating auth module properly or using tokenNotExpired for logged in check. IF anyone is inclined, feel free to roll out those incremental PRs.

jmrapp1 · 2017-07-27T19:43:35Z

To give some type of direction for whomever wants to move ahead with the changes, here is what I'd suggest:

Passport & JWT. Transition to using passport for route authentication. Passport is a middleware that allows you to authenticate "strategies" that you predefine. These strategies act as a security layer to your express routes. For JWT tokens I highly suggest using the passport-jwt module that allows you to easily authenticate a JWT token that is generated when a user logs in.
Server-Side JWT Implementation. Now that passport and passport-jwt are in, you can create a JWT token when a user logs in, send it to them, and then they will attach the token to the header whenever they go to a secure route. The passport-jwt documentation gives an example of how you can use it as middleware for authentication.
Client-Side JWT Implementation. This part is pretty much finished thanks to the changes on this branch. There may be a few small changes, but overall using the AuthHttp module for the secure routing will handle everything.

DavideViolante · 2017-10-10T19:12:19Z

server/controllers/base.ts

+    if (!req.payload.user._id) {
+      res.status(401).json({
+        'message' : 'UnauthorizedError: private'
+      });


These 4 lines (7-10) are repeated throughout the entire file. There is surely a better way to write this part, in a way to respect the DRY principle.

i am trying to say that i have already implemented similar kind of workout

dougal83 · 2018-01-07T22:34:38Z

Closing PR. Revision needed.

Follow up: New PR

dougal83 added 2 commits July 13, 2017 10:42

secured api /w express-jwt [issue 58]

c6a3a37

removed redundant headers from AuthHttp calls

6a08d2c

jmrapp1 reviewed Jul 22, 2017

View reviewed changes

dougal83 changed the title ~~secured api /w express-jwt [issue 58]~~ WIP secured api /w express-jwt [issue 58] Jul 26, 2017

yusufcanb approved these changes Aug 28, 2017

View reviewed changes

yusufcanb approved these changes Sep 1, 2017

View reviewed changes

Merge branch 'master' into feature/58/secure-api

d454b3f

DavideViolante reviewed Oct 10, 2017

View reviewed changes

Repository owner deleted a comment from Thavarajan Oct 11, 2017

DavideViolante added 2 commits November 4, 2017 11:52

Merge branch 'master' into feature/58/secure-api

08f40d3

Merge branch 'master' into feature/58/secure-api

597f207

DavideViolante changed the title ~~WIP secured api /w express-jwt [issue 58]~~ Secure api with express-jwt (wip) Nov 4, 2017

dougal83 closed this Jan 7, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Secure api with express-jwt (wip) #82

Secure api with express-jwt (wip) #82

dougal83 commented Jul 13, 2017 •

edited by DavideViolante

Loading

jmrapp1 commented Jul 21, 2017 •

edited

Loading

jmrapp1 Jul 22, 2017

dougal83 Jul 22, 2017

DavideViolante Oct 10, 2017 •

edited

Loading

dougal83 commented Jul 22, 2017 •

edited

Loading

jmrapp1 commented Jul 22, 2017 •

edited

Loading

dougal83 commented Jul 22, 2017 •

edited

Loading

jmrapp1 commented Jul 24, 2017

DavideViolante commented Jul 24, 2017 •

edited

Loading

jmrapp1 commented Jul 26, 2017

dougal83 commented Jul 26, 2017

jmrapp1 commented Jul 27, 2017 •

edited

Loading

DavideViolante Oct 10, 2017

Thavarajan Oct 11, 2017

dougal83 commented Jan 7, 2018 •

edited

Loading

Secure api with express-jwt (wip) #82

Secure api with express-jwt (wip) #82

Conversation

dougal83 commented Jul 13, 2017 • edited by DavideViolante Loading

jmrapp1 commented Jul 21, 2017 • edited Loading

jmrapp1 Jul 22, 2017

Choose a reason for hiding this comment

dougal83 Jul 22, 2017

Choose a reason for hiding this comment

DavideViolante Oct 10, 2017 • edited Loading

Choose a reason for hiding this comment

dougal83 commented Jul 22, 2017 • edited Loading

jmrapp1 commented Jul 22, 2017 • edited Loading

dougal83 commented Jul 22, 2017 • edited Loading

jmrapp1 commented Jul 24, 2017

DavideViolante commented Jul 24, 2017 • edited Loading

jmrapp1 commented Jul 26, 2017

dougal83 commented Jul 26, 2017

jmrapp1 commented Jul 27, 2017 • edited Loading

DavideViolante Oct 10, 2017

Choose a reason for hiding this comment

Thavarajan Oct 11, 2017

Choose a reason for hiding this comment

dougal83 commented Jan 7, 2018 • edited Loading

dougal83 commented Jul 13, 2017 •

edited by DavideViolante

Loading

jmrapp1 commented Jul 21, 2017 •

edited

Loading

DavideViolante Oct 10, 2017 •

edited

Loading

dougal83 commented Jul 22, 2017 •

edited

Loading

jmrapp1 commented Jul 22, 2017 •

edited

Loading

dougal83 commented Jul 22, 2017 •

edited

Loading

DavideViolante commented Jul 24, 2017 •

edited

Loading

jmrapp1 commented Jul 27, 2017 •

edited

Loading

dougal83 commented Jan 7, 2018 •

edited

Loading