Javascript客户端身份验证（使用SSL，没有OAuth2）？

Question

The scenario is:

I have a web API, which is being accessed by two clients:

• Web App written in Javascript, which is minified
• iOS App

SSL is all set up on the server hosting the API, and it works fine. There is no User Auth for the API because it's a sort of location-based searching app.

I want to ensure though that only the web app and the iPhone client are able to actually make requests to the API. For the iPhone client it's easy - a shared secret between the server and the app will do, and it's encrypted with SSL so we're not worried about people spying on it.

But for the web app the same solution won't work. I can't just leave a string in the code, and even if it's encrypted in there that's all somebody would need.

Basically, I'm looking for a good solution to this problem. I just want to make sure it's kept only to clients who are allowed to use it, but I'm not sure how I can without going and implementing OAuth which I think is probably overkill. Any ideas?

Thanks! Dan

Answer 1

It can't be done. Even with oauth. Even assuming that your iOS app is secure, is wrong: it can be decompiled. Any code that runs on the client, can be tampered with, and can't be trusted to be who he says he is.

Only question is: is the API you provide valuable enough, and how much trouble would someone want to go through to hack it. And how hard do you want to make it for whomever wants to hack it.

The iOS version is indeed way safer than the javascript version. In the webapp you can obfuscate your code to make it harder to hack. You can (if you don't intend to use it on iOS) use java or flash to further hide your signing code (HMAC-sign your requests, don't just send a shared secret with them. You may think SSL is secure, but there is a moment before the url is encrypted....).

The way the "big guys" deal with this is:

• Whatever you build, assume that someone will be able to hack it (as in: use your API for some other purpose than you intended).
• Think about how bad this really is (note: they wouldn't be able to build a business on it; it would be WAY TOO vulnerable to lawsuits). Is it really the end of the world if a lone wolf uses your API.
• If you do care about the lone wolves, make it as hard as possible (but honestly, isn't it cheaper just to loose some money from the lone wolves, than to spend 2 developer-months on it?)
• If somehow there is serious interest in hacking into your API, try to come to an understanding with the hackers (eg I like the way how Spotify reacted to despotify. Basically they said "hey, if you don't release anything that makes it really easy to steal our music or circumvent our businessmodel, we won't try too hard to block you")