https://github.com/jaredhanson/oauth2orize and check out passport.js
On Wed, May 1, 2013 at 2:40 PM, Matthew Page <matthewnp...@gmail.com> wrote: > Have a look at: > > https://github.com/bnoguchi/everyauth > or > https://github.com/ciaranj/node-oauth > > > On Wed, May 1, 2013 at 2:29 PM, Dick Hardt <dick.ha...@gmail.com> wrote: > >> 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 <empty...@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 nodejs@googlegroups.com >>> To unsubscribe from this group, send email to >>> nodejs+unsubscr...@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+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> >> >> -- >> -- Dick >> >> -- >> -- >> 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 nodejs@googlegroups.com >> To unsubscribe from this group, send email to >> nodejs+unsubscr...@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+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- > -- > 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 nodejs@googlegroups.com > To unsubscribe from this group, send email to > nodejs+unsubscr...@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+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- 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 nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
