Re: [nodejs] Best practices for token-based authentication in REST API

[Dick Hardt]

Using OAuth 2.0 does not imply that you are using Google or other 3rd party provider.

The flow you described is what OAuth 2.0 does. OAuth 2.0 is commonly used by a mobile app to obtain an access token that is then used for subsequent API calls by the mobile app. Sorry the RFC does not make that as clear as it should.

On Wed, May 1, 2013 at 10:20 AM, Alan Fay <empt...@gmail.com> wrote:

Hello!

I'm trying to develop a REST API using node.js, to support an Android app.  I've been able to find several resources on the web, however, most of the examples I come across fall into two camps:

1) Basic authentication over HTTPS

2) OAuth

I don't want to do basic authentication over HTTPS with a username and password, because in the Android app, I have it setup to store a username and token via the AccountManager (they seem to have taken down reference to the code on Android's site; my implementation is very similar the sample code that ships with the SDK: android-sdk-linux/samples/android-17/SampleSyncAdapter except I'm not using any of the Sync features).

I don't want to use OAuth because I am not sure we can count on users to have accounts with Google or some other third-party OAuth provider.

This is my first round at implementing web authentication; from what I'm reading, the steps go something like this:

- [Service] Administrator creates an account with a username and a generated strong code is stored temporarily in the user record; emailed to user

- [App] User selects account and enters username and code, plus password of their choice, into the form

- [App] Basic authentication over HTTPS sends over username, code, and password (just this once)

- [Service] Stores random salt and password hash in the user record, and the generated token (a)

- [Service] Replies back to App with the token

- [App] Username and token is stored via AccountManager

Then,

- [App] User sends username and token to service (b)

- [Service] authenticates the user if the token matches and is not expired (c)

- [App] User can access the various REST API calls (d)

In this way, the password is never stored on the Android device or in the database.  When the token expires, then User re-enters password.  The User can request a password reset, which generates a strong code again and the process starts from the top.

My questions (referenced above) are:

(a) Should the generated token be stored on the user record, or in a separate table?  My thinking for a separate table/collection would be to have a background process that could remove expired tokens; keeping this information separate from the user record; or perhaps a user could have a valid reason to have multiple different tokens (one on the phone, another on the tablet).

(b) Is this simply done through basic authentication over HTTPS, sending the username and token (in place of password)?

(c) I've seen examples of node.js code setting values on request.session; effectively, marking the session as authenticated.  Is this specific to browsers/cookies and/or does it work when communicating to Android?

(d) Kind of an extension of (c), does the username/token have to be sent every time, or can I reference something like the request.session.authorized value?

Also:

- Does anyone know of a good working example of a node.js REST API implementation for an Android app?  Sometimes it's easier to just learn from code.

- Is there working example code of the node dependencies I see referenced everywhere (everyauth, connect-auth, passport) being used with an Android app?  Most seem to implement OAuth solutions.

- Any security/implementation pitfalls with this approach?

References:

* [The Definitive Guide to Forms-based Website Authentication](http://stackoverflow.com/a/477578/172217)

* [Designing a Secure REST (Web) API without OAuth](http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/)

* [How to Implement a Secure REST API with node.js](http://stackoverflow.com/a/15500784/172217)

* [RESTful Authentication](http://stackoverflow.com/a/7158864/172217)

* [Securing my node.js App REST API](http://stackoverflow.com/a/9126126/172217)

* [Connect Session Middleware](http://www.senchalabs.org/connect/session.html)

* [Secure Salted Password Hashing](http://crackstation.net/hashing-security.htm)

--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
 
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
-- Dick

[Matthew Page]

Have a look at:

https://github.com/bnoguchi/everyauth

or

https://github.com/ciaranj/node-oauth

[Martin Wawrusch]

https://github.com/jaredhanson/oauth2orize and check out passport.js

[José F. Romaniello]

what most people do is to open a webview for authentication, you can use oauth or any authentication mechanism, after finishing the oauth flow you get a token into your android app

If you need to access an api from the same Identity Provider, you might just get the access token into the android app and then use that token on every request. 

If you want to access your own REST api you need to generate a token yourself and handle expiration. I will strongly recomend to have a look to JWT (json web token)

http://openid.net/specs/draft-jones-json-web-token-07.html

http://coderead.wordpress.com/2012/08/16/securing-node-js-restful-services-with-jwt-tokens/

https://github.com/hokaccha/node-jwt-simple

We use JWT with Windows Azure Mobile Service

http://blog.auth0.com/2013/03/17/Authenticate-Azure-Mobile-Services-apps-with-Everything-using-Auth0/

regards

2013/5/1 Alan Fay <empt...@gmail.com>

[Domenic Denicola]

OAuth 2 is definitely what you're looking for. In particular it looks like you want the Resource Owner Password Credentials flow.

If by chance you are using Restify, I made a thing that will automatically handle this for you: Restify–OAuth2. Even if you're not, take a look at the readme to understand the basic RESTful flow of authentication, and at the code and example server to see the basic idea implementations.

[José F. Romaniello]

With the Resource Owner Password Credentials flow you need to have the resource owner credentials (client id and secret)  embed in your android application.

This is not good, no matter how hard you obfuscate. Few weeks ago someone published the client id and client secret that all versions of Twitter for OS[x] uses.

https://news.ycombinator.com/item?id=5337099

--

[Alan Fay]

On Thursday, May 2, 2013 6:24:57 AM UTC-4, José F. Romaniello wrote:

With the Resource Owner Password Credentials flow you need to have the resource owner credentials (client id and secret)  embed in your android application.

This is not good, no matter how hard you obfuscate. Few weeks ago someone published the client id and client secret that all versions of Twitter for OS[x] uses.

Yes, great points: I specifically want to avoid storing anything that would be useful to an attacker on the app locally.

Thanks for all the helpful replies!  I decided to look into a jwt-simple implementation going forward in the next few days.

[Alex Kocharin]

Hmm... Resource Owner Password flow looks very much like session_id cookies in browser applications. Is it really the same thing named differently, or am I missing something here?

[Nik Martin]

I deleted this and reposted, because I forgot to address one of your questions, which I did in this edit:

I'm going to vastly over simplify this, but it holds up if you have any HTTP/Node.js experience.  I have closely examined 2 authentication schemes: Cloudstack, Amazon AWS, and both implementations are WAY simpler than you think, and are as good as implementing two-legged OAUTH which both are very similar to.  You'll WANT to do this yourself as (my opinion) you REALLY need to understand how your app is authenticating, and besides it's easy.

http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ 

This link you posted is 95% of how AWS and Cloudstack do it.  The main difference is that they use a stored API Key and API Secret that are associated with your user ID.  That's fine, but then you have to store stuff on the phone, or pass the secret over the wire (NEVER NEVER NEVER).  Why not use The user ID and Password (with complexity rules) as the API key and Secret?  This way, they are only stored in the app's memory, and when the app goes away, the "session" dies, like it should. The phone also has a screen lock, right?  So the user is partially responsible for the security of his data as he should be. Also, MFA is 100% required IMO if you are going to actually secure from man-in-the-middle.  Authy is cheap, and easy, brain-dead-easy to implement. OK, on to some code: https://gist.github.com/nikmartin/5499838  That's it.  Do that on both client and server for EVERY REST call, and you've done it, with very high  security.  Now, to go even further, taking the MFA concept of a very short lived token, AFTER signing the request, add a UNIX UTC timestamp to your payload, and on the server, check it to ensure it's within x seconds of the server time. This prevents replay attacks.  One more add-on, I think from that buzzmedia article, is to also add the URI and HTTP verb into he signature, again to prevent hijacking a signed request to replay against another URI/VERB, like hijacking "getUserAccount" to "deleteUser", etc.

 

Password storage: this can be pretty simple as well, as simple as concatting the password with the username, then salting the password with that. So when the user authenticates, he can salt the password on the client before sending, and you can store it salted. Salts don't have to be secret, they just guard against rainbow attacks, and the client knows the salt, because it's his username+password

If you or anyone else can punch a hole in that, be my guest, as I'm implementing this my self at this very moment with Node, Android, mongoose+mongoDB, and Authy, and haven't found a simpler scheme yet.

Nik

[Luke Arduini]

What happens when authy goes down? Your users just don't log in?

--

[Alan Fay]

Resurrecting this thread.  I am still lost as ever on oauth.

Our project switched to restify instead of express, because we didn't need the HTML rendering bits - just wanted to implement an API with authentication.

On Wednesday, May 1, 2013 1:20:24 PM UTC-4, Alan Fay wrote:

Also:

- Does anyone know of a good working example of a node.js REST API implementation for an Android app?  Sometimes it's easier to just learn from code.

- Is there working example code of the node dependencies I see referenced everywhere (everyauth, connect-auth, passport) being used with an Android app?  Most seem to implement OAuth solutions.

I've been trying to find a real-world, working example of ANY node.js project using oauth, on github or wherever.  Does anyone know of examples like this?

[Mark Hahn]

My module uses oauth2: https://github.com/mark-hahn/basecamp.

--

[Modika]

Hi Alan,

 

We are actually building using the exact same stack.  At the moment we are building out a web application that will be initially at least be the only client (we will move to mobile etc)  Because we are only looking at trusted apps at the beginning the full work flow for this hasn't been outlined, what i mean is we haven't bothered initially with implementing other strategies for oAuth that will allow for third party apps we are only concerning ourselves with trusted client Auths.

 

We have done a few spikes as even the the overall flows are simply to view and visualise the actual protocol itself can be complex.  We have currently settled (and someone mentioned this above) on using Auth2orize with passport.js based strategies.

 

As we are doing this based on a trusted app we are using the Resource Owners Pasword Credentials which eliminates the dialog for us as means we can use a traditional login form to authenticate the user and return a bearer token to authorise them moving forwards.  If we we were working with 3rd parties who wanted access to our API then we would use one of the other flows so that the username and password do no touch the 3rd party application but as i said we know the consumer here.

 

They way we are doing it is using oAuth2rize to create a token server routed to something like http://api.somewhere.com/token and posting to this location:

 

POST https://api.somewhere.com/token

    grant_type=password&

    username=USERNAME&

    password=PASSWORD&

    client_id=CLIENT_ID

 

The below is sample code, it may or may not be 100% correct or working but you should be able to find most of this stuff in the sample application on the oAuth2orize Github example application.

 

We decided that our flow would be for this kind of exchange:

 

1 – Validate the client (using the ClientPasswordStrategy of passport.js)

2 – Setup a hook to catch the password exchange flow (Resource Owners Pasword Credentials) and do a simply validation of user credentials to validate that the user exists and that the credentials are correct

3 – Generate a token and store the details of the exchange in Redis (User, Client token etc) which we then use as our token store and place to cross reference tokens

4 – Subsequent requests are checked using the BearerTokenStrategy of passport.js to ensure the token is still valid.

 

Hope that helps!
Rob

[Alan Fay]

On Sunday, May 26, 2013 1:17:26 PM UTC-4, Mark Hahn wrote:

My module uses oauth2: https://github.com/mark-hahn/basecamp.

Yes, you're using the oauth protocol to call into an existing API.  There's some good examples of this on the web.  That's what is making it hard for me to find good working examples.

I am hoping to find a (working) example that implements authentication - a node.js server implementing a REST API using oauth2 or oauth2ize or passport.  There's sample code in these projects, but I have little luck getting them to work.  I'm just missing something in the code and it'll help to see it in the context of a working demo app.

Is there a working github project that uses passport (or oauth2, or oauth2ize) in a restify project?

[Roberto Modica]

Your probably not going to find a "fully scoped" example because the protocol is complex and has a lot different routes and permitations and it depends on how you are going to use it. Like i said we use passport.js and the different strategies with oAuth2rize and the sample app that has been put together does give a good outline to what is possible, thats how we worked it out. We may decide to write our own implementation but for now our time is spent building core logic.

[Alan Fay]

On Tuesday, May 28, 2013 5:46:54 PM UTC-4, Roberto Modica wrote:

Your probably not going to find a "fully scoped" example because the protocol is complex and has a lot different routes and permitations and it depends on how you are going to use it.  Like i said we use passport.js and the different strategies with oAuth2rize and the sample app that has been put together does give a good outline to what is possible, thats how we worked it out.  We may decide to write our own implementation but for now our time is spent building core logic.

I'll just have to do the same (trial and error) until I get it working the way I want with one of those libraries.  If that gets done, I'll post up the fully working example, so there's at least one example of how to do this on the internet.

[Andy Ennamorato]

What about Persona (browserid) from Mozilla? I know it's a little off the mark but maybe it's useful as an example - https://github.com/mozilla/browserid

Interested to see what you come up with at any rate.

Andy

Sent from my iPhone

--

[Sven Dens]

Ok, I may have been wrong about oAuth 2.0 not being suitable for such an approach.

Reading this page, it looks like it's possible to implement oAuth 2.0 to do just what I've written using JWT tokens (or nonce's for that matter): https://developers.google.com/accounts/docs/OAuth2ServiceAccount.

But still, it would imply you to setup an oAuth 2.0 provider yourself, if I'm understanding things correctly.

Any experts on the subject: please comment.

I'm off to my man cave to start putting some ideas on paper :-)

On Wednesday, May 1, 2013 7:20:24 PM UTC+2, Alan Fay wrote:

Hello!

I'm trying to develop a REST API using node.js, to support an Android app.  I've been able to find several resources on the web, however, most of the examples I come across fall into two camps:

1) Basic authentication over HTTPS

2) OAuth

I don't want to do basic authentication over HTTPS with a username and password, because in the Android app, I have it setup to store a username and token via the AccountManager (they seem to have taken down reference to the code on Android's site; my implementation is very similar the sample code that ships with the SDK: android-sdk-linux/samples/android-17/SampleSyncAdapter except I'm not using any of the Sync features).

I don't want to use OAuth because I am not sure we can count on users to have accounts with Google or some other third-party OAuth provider.

This is my first round at implementing web authentication; from what I'm reading, the steps go something like this:

- [Service] Administrator creates an account with a username and a generated strong code is stored temporarily in the user record; emailed to user

- [App] User selects account and enters username and code, plus password of their choice, into the form

- [App] Basic authentication over HTTPS sends over username, code, and password (just this once)

- [Service] Stores random salt and password hash in the user record, and the generated token (a)

- [Service] Replies back to App with the token

- [App] Username and token is stored via AccountManager

Then,

- [App] User sends username and token to service (b)

- [Service] authenticates the user if the token matches and is not expired (c)

- [App] User can access the various REST API calls (d)

In this way, the password is never stored on the Android device or in the database.  When the token expires, then User re-enters password.  The User can request a password reset, which generates a strong code again and the process starts from the top.

My questions (referenced above) are:

(a) Should the generated token be stored on the user record, or in a separate table?  My thinking for a separate table/collection would be to have a background process that could remove expired tokens; keeping this information separate from the user record; or perhaps a user could have a valid reason to have multiple different tokens (one on the phone, another on the tablet).

(b) Is this simply done through basic authentication over HTTPS, sending the username and token (in place of password)?

(c) I've seen examples of node.js code setting values on request.session; effectively, marking the session as authenticated.  Is this specific to browsers/cookies and/or does it work when communicating to Android?

(d) Kind of an extension of (c), does the username/token have to be sent every time, or can I reference something like the request.session.authorized value?

Also:

- Does anyone know of a good working example of a node.js REST API implementation for an Android app?  Sometimes it's easier to just learn from code.

- Is there working example code of the node dependencies I see referenced everywhere (everyauth, connect-auth, passport) being used with an Android app?  Most seem to implement OAuth solutions.

- Any security/implementation pitfalls with this approach?

References:

* [The Definitive Guide to Forms-based Website Authentication](http://stackoverflow.com/a/477578/172217)

* [Designing a Secure REST (Web) API without OAuth](http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/)

* [How to Implement a Secure REST API with node.js](http://stackoverflow.com/a/15500784/172217)

* [RESTful Authentication](http://stackoverflow.com/a/7158864/172217)

* [Securing my node.js App REST API](http://stackoverflow.com/a/9126126/172217)

* [Connect Session Middleware](http://www.senchalabs.org/connect/session.html)

* [Secure Salted Password Hashing](http://crackstation.net/hashing-security.htm)

[Sven Dens]

Über-simplified flowchart of how a registration process for a protected API might come together: https://dl.dropboxusercontent.com/u/30446781/webshots/deltablock007.png.

I'm building some first lines of code while we speak.

Will publish a first alpha take on github when complete & post here.

--

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
 
---

You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/2zCXZ10jFbg/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to nodejs+un...@googlegroups.com.

[Dick Hardt]

I am confused as to who you think the various players are. OAuth 2 is not all that complicated. Don't let all the flows get you confused. Send a link to the various players and trust relationships I'd be happy to give you some guidance.

On Tue, Jun 11, 2013 at 7:47 AM, Sven Dens <sven...@gmail.com> wrote:

Hi Nik,

I had been reading the buzzmedia article too, and I appreciate your idea of using the user+pass as the salt for the password & just storing the salted password on your server. However, I see a couple of drawbacks to this approach:

1/ If you are exposing an API to be used by an app YOU wrote yourself, then there is no problem (besides drawback #2). BUT, if you are exposing an API that is to be used by third-party apps, then using this approach would require the credentials to login to this third-party app to be the same as the credentials for authenticating to your API. Suppose you want to grant access to your API to a third-party app, then this app cannot "transparently" communicate with your API without requiring it's users to login to the app itself too, which may not be a use case for all apps. The third-party app maintainer would also know that you could now probably impersonate anyone in THEIR app, which is not something I would be ok with if I were that person.

2/ API authentication would be on a per-user basis, not on a per-app basis. This means you have no real way of knowing which apps are communicating with your API, you just know which users are. This also means you cannot enforce an app to have a minimum version number, in case some version of an app got compromised or should be banned from using your API for one reason or another. Whereas when you bind an API key to an app, AND have a new key for every version of that app, these things would be trivial.

I'm still cracking my head on how to get around those 2 limitations. Best I can think of right now is to DO store an API key & secret in the app that is sent over the wire using SSL. That way I'm eliminating the problems with 1/ and 2/. If an app should get compromised, I revoke the key on the server side and gone is the API access.

I think this is an interesting discussion, seeing that anything I can find on this subject goes out from the assumption that you are writing an API for a service where people have a user account with you, and you want to allow third-party apps to be able to retrieve some of your users' private data after this has been approved by the user himself. This may be the case for the Facebook's and the Twitter's in this world, but suppose for a minute that you are offering a data service that has nothing to do with users... 

Say I am running a bank and I want to expose an API through which other apps may request a list of bank offices. If I were using oAuth(2), any app user would have to authenticate the app to perform certain actions on my API so the app could receive a token? No, that's not what I want! I just want to be able to open up my API to third-party apps, and I want to control which calls can be made by which app. I want to be in control of what is allowed on my API and by whom. It's not up to an app user to decide what that app may or may not ask from my API. So I just want to issue an API key & secret to an app that define what parts of my API that app can use. And then I want to use the signature approach to have fine-grained control over my API access.

This would not require a third-party app to have their users login, nor would it require any user action to let the app communicate with my API, nor would it rely on any third party to authenticate an app with my API, and nor would it prohibit me from determining exactly which access is allowed from which (version of an) app.

I may be missing something about oAuth2 completely as to why I'm thinking I could not use it for such an approach though. If anyone could challenge & clarify that for me, please do.

Sven

--

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
 
---

You received this message because you are subscribed to the Google Groups "nodejs" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.

[Mikeal Rogers]

OAuth 1 is a pain in the ass but mostly secure and consistent across implementations.

OAuth 2 is fairly easy and inconsistent across implementations as well as being very insecure.

The author of both specs is a node developer now and has left the standards world to do this stuff "right" :)

https://github.com/hueniverse/oz

https://github.com/hueniverse/hawk

Reference implementations are, of course, in node.js. 

request supports OAuth signing as well as hawk signing.

-Mikeal

[Dick Hardt]

Hmmm ... Erin was not the author of OAuth 2.0 He was the IETF editor of the OAuth WG when the OAuth 2.0  proposal (OAuth WRAP) was presented to the OAuth WG.

The main insecurity in OAuth 2.0 are the implicit flow that Facebook added to the specification so that they could do a flow that was in client side JavaScript.

There is little (if any) industry support for Oz.

[Sven Dens]

Well... you need an Authorization server, so that's one player. And you have your client, player 2. Client asks the server for a token. Server validates credentials and looks up privileges. Server returns a token that can be used for a certain amount of time, and the token determines which access is given to an API.

But still, this all keeps revolving around tokens that allow access to an API that provides USER data ("Web applications or installed applications can use the new, simplified OAuth 2.0 protocol to authorize access to data associated with a Google account. For details and examples of how to implement OAuth 2.0 with Google, see our documentation on OAuth 2.0." => https://developers.google.com/accounts/docs/GettingStarted). So still not suitable for an API you own privately that has nothing to do with users.

I cannot send you any links though. What I'm trying to do is to learn & understand how one could do this, I don't have a specific use case for it at the moment. Just take my fictional example: I am a bank and want to expose a secured API through which third parties can ask for a list of bank offices. How would you best do this? 

You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/2zCXZ10jFbg/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to nodejs+un...@googlegroups.com.

[Sven Dens]

Wow, those are nice links Mikeal. Very interesting read, thanks!

You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/2zCXZ10jFbg/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to nodejs+un...@googlegroups.com.

[Sven Dens]

I'm doing what I should have been doing in the first place before starting to ask questions; reading these texts:

http://en.wikipedia.org/wiki/OAuth

http://tools.ietf.org/html/rfc5849

http://tools.ietf.org/html/rfc6749

http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/

That clears things up!

For anyone else struggling to understand this: the part I was missing all along is that, when you want to use oAuth (1 or 2) for your own API, YOU need to become an oAuth provider. I was missing the ball by thinking I could use some external oAuth provider to delegate authentication to, and receive a token in return that could be shared between my API and a client app. Which is total nonsense of course. I get it now though :-)

Thanks everyone for all your input!