Wow, those are nice links Mikeal. Very interesting read, thanks!
On Wed, Jun 12, 2013 at 3:40 AM, Mikeal Rogers <mikeal.rog...@gmail.com>wrote: > 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 > > On Jun 11, 2013, at 6:30PM, Dick Hardt <dick.ha...@gmail.com> wrote: > > 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.d...@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 >> >> >> On Friday, May 3, 2013 8:57:22 PM UTC+2, Nik Martin wrote: >>> >>> 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/<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<https://www.authy.com/> is >>> cheap, and easy, brain-dead-easy to implement. OK, on to some code: >>> https://gist.github.com/**nikmartin/5499838<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 >>> >>> On Wednesday, May 1, 2013 12:20:24 PM UTC-5, 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 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 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+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.
