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.
