Feature request: Token-based auth for REST API

[colinskow]

Cookie-based auth doesn't work on Phonegap or Chrome packaged apps. It also leaves vulnerability to CSRF attacks.

A better strategy for an Angular-type SPA is to store a token in LocalStorage:
https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/

I would like the options to use either json web tokens (which don't require any session store) or a Redis-based token system. This is very easy to implement with Passport.

https://github.com/roblevintennis/passport-api-tokens

If I have some time over the next week I'll send you a pull request.

[zemirco]

Why doesn't cookie based authentication work on PhoneGap? How is the PR going?

[colinskow]

From what I understand cookie auth is a bad practice in general with REST APIs. Malicious scripts from other websites can make calls to the API if a session cookie is set.

What I'm working on is translating the MEAN.io stack into the "CANE" stack. (CouchDB, Angular, Node, Express) It will use PouchDB as the adapter on both client and server, and will be awesome for creating offline applications that sync automatically.

I am going to use your sendmail / forgot password / failed login tracking. However the other changes I want to make will most likely break your API, so it is probably best as a separate project.

MEAN has most of the base code I need. I am going to modify it to use CouchDB as the backend, and use your forgot password / confirm email functionality.

I am also working on a validation package for CouchDB to be able to validate user input similar to Mongoose.

It seems our interests are very much aligned, so perhaps after I get the project off the ground we can work together.

[zemirco]

Where did you get that from?

From what I understand cookie auth is a bad practice in general with REST APIs. Malicious scripts from other websites can make calls to the API if a session cookie is set.

It's simply not true.

Lockit doesn't strive to be a one-size-fits-all solution. It provides user authentication using email/username and password. Lockit is independent from any database and from any frontend framework. It can be part of your W stack (whatever stack (c) myself) though. Therefore I don't think our interests are very much aligned but I'm happy about quality pull requests.

[jamescam22]

@zemirco, colinskow is absolutely correct. Cookie authentication is not acceptable in a wide variety of scenarios. If you went so far as to make lockit work with a variety of backends and databases, why wouldn't you also invest the 40 minutes it would take to simply allow cookie or token auth? Or it would probably take a couple hours to simply make the authentication mechanism pluggable to support any type of medium. You've already done the hard work supporting multiple backends and databases, but at the very last mile you are quitting. This is the only reason I'm not using lockit, and I have a couple of friends who told me this was the main drawback of lockit.

[VipulVikas]

Hi, I am facing this issue for a long time. Although I was able to use local storage approach for basic AJAX calls, I am not able to use it for playing videos in my app.
Videos are accessed through URLs which require basic authentication.
How can this be achieved?

[zemirco]

Anyone willing to write a pull request? Otherwise I have to close the issue.

[colinskow]

I ended up building my own Express/CouchDB authentication framework from scratch. It is 100% cookie-free and designed for APIs and single-page apps rather than server-rendered sites. It comes complete with AngularJS bindings and a working live demo. It manages permissions on multiple per-user and shared CouchDB and Cloudant databases.

https://github.com/colinskow/superlogin

But you were right Mirco... Authentication is a lot of work when done by scratch!