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 El 02/05/2013 03:41, "Domenic Denicola" <[email protected]> escribió: > 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<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/<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 <http://stackoverflow.com/a/15500784/172217>) >> * [RESTful >> Authentication](http://**stackoverflow.com/a/7158864/**172217<http://stackoverflow.com/a/7158864/172217> >> ) >> * [Securing my node.js App REST API](http://stackoverflow.com/** >> a/9126126/172217 <http://stackoverflow.com/a/9126126/172217>) >> * [Connect Session Middleware](http://www.**senchalabs.org/connect/** >> session.html <http://www.senchalabs.org/connect/session.html>) >> * [Secure Salted Password Hashing](http://crackstation.** >> net/hashing-security.htm <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. > > > -- -- 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.
