OAuth 2 is definitely what you're looking for. In particular it looks like you want the Resource Owner Password Credentials<http://tools.ietf.org/html/rfc6749#section-1.3.3>flow.
If by chance you are using Restify, I made a thing that will automatically handle this for you: Restify–OAuth2<https://github.com/domenic/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. On Wednesday, May 1, 2013 1:20:24 PM UTC-4, 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) > -- -- 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 [email protected] To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
