Manage API request from different clients

[jtomasrl]

I'm making an API so users can login (without registering) and use some methods, I want an app that work in stores, every store is registered on the service so the clients get inside the store, scan a code and cand view information related to the store. But I dont now really well how yo handle this, if I should add a public key inside that code to encrypt the files and send an store id with the request params to get the correct information or what, It could be very helpful some advices or a little help, I dont have any experience creating API's.

[sune jakobsson]

Are you talking about a location restricted app? So that it would work inside a store on their open wireless network? 

Sune

On 16 September 2012 05:02, jtomasrl <jtom...@gmail.com> wrote:

I'm making an API so users can login (without registering) and use some methods, I want an app that work in stores, every store is registered on the service so the clients get inside the store, scan a code and cand view information related to the store. But I dont now really well how yo handle this, if I should add a public key inside that code to encrypt the files and send an store id with the request params to get the correct information or what, It could be very helpful some advices or a little help, I dont have any experience creating API's.

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group, send email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft?hl=en.
 
 

[jtomasrl]

It has a public part when you can see all stores and a restricted one where depending on in which store you are you have it's own information

[Mike Kelly]

Would something like this be adequate?

> POST http://company.com/find-shop
{ "my-coordinates": [10,10] }

< 302 + Location: http://shop-a.company.com

Cheers,
M

> --
> You received this message because you are subscribed to the Google Groups
> "API Craft" group.
> To unsubscribe from this group, send email to
> api-craft+...@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
>
>

--
Mike

http://twitter.com/mikekelly85
http://github.com/mikekelly
http://linkedin.com/in/mikekelly123

[jtomasrl]

Not really, I need to be able to send sensitive information

[Mike Kelly]

I've heard it is possible for android apps to make a device connect to
a specific wifi access point so you could try going down that route -
pretty sure you can't do that with iOS though so you will need a
separate solution for that.

[jtomasrl]

thx for the top but i dont think that that its what im looking for

[David Eriksson]

Create one app for each store. Each app contains a hardcoded key that identifies the store and is sent with all API requests. 

To protect the key and data from easy wiretapping, use HTTPS for transport (with a REAL certificate, not a self-signed).

As a bonus you can generate new keys for every release of the app and decide on the server side what keys should map to what store, and how long old keys will be valid.

Best regards,

David Eriksson

http://www.divideandconquer.se/

[jtomasrl]

that was what i was thinking of, but should I encrypt the data by my self or will HTTPS do the job?

[David Eriksson]

I'd say that HTTPS (with a REAL certificate) should satisfy 99% of all use cases.

If we are talking about protecting the server from an attacker, you can actually never know if a client is the app you created, or if a persistent and attacker has disassembled the app, extracted the protocol and any secrets (server key, encryption keys), and has created their own application that is indistinguishable from the real thing. Adding more encryption and obfuscation may delay the attacker slightly, but will also make your protocol much harder to implement on both server and client, require more code where bugs may be found, and will be harder to debug.

That said, you may want to investigate 2-legged OAuth for authenticating the app with the server.

Cheers,

\David

[sune jakobsson]

So instead you need to evaluate what is at stake here. If the app "only" provides some promotions/discount, then the store might be fine as long as they get paying customers.

HTTPS will protect you from eavesdropping, but not from re-engineering the app, so that it looks like the real thing, unless you use a OTP in some other communication channel, to verify the end-user identity.

Sune

[jtomasrl]

I was thinking on having a QR code containing a store_id and a key (like a password) so the user scans it using my app, the key is send and the user is "logged in" using oauth or something like this. Also using HTTPS

[sune jakobsson]

But back to your initial question, there is nothing stopping a "friend" from taking a picture of the QR code, and then let "someone" do a brute force attack, or a DoS on the server.

So what is at stake here is the most interesting question you need to answer.

Sune 

--

[jtomasrl]

Maybe combining the QR code and limiting de area from a map, dont know really how to manage this