I'm doing what I should have been doing in the first place before starting to ask questions; reading these texts: http://en.wikipedia.org/wiki/OAuth http://tools.ietf.org/html/rfc5849 http://tools.ietf.org/html/rfc6749 http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/
That clears things up! For anyone else struggling to understand this: the part I was missing all along is that, when you want to use oAuth (1 or 2) for your own API, YOU need to become an oAuth provider. I was missing the ball by thinking I could use some external oAuth provider to delegate authentication to, and receive a token in return that could be shared between my API and a client app. Which is total nonsense of course. I get it now though :-) Thanks everyone for all your input! On Wed, Jun 12, 2013 at 11:00 AM, Sven Dens <[email protected]> wrote: > Wow, those are nice links Mikeal. Very interesting read, thanks! > > > On Wed, Jun 12, 2013 at 3:40 AM, 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 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 >> [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.
