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. On Tue, Jun 11, 2013 at 6:40 PM, Mikeal Rogers <[email protected]>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 <[email protected]> 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 <[email protected]> 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 [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. > > > > > -- > -- > 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.
