Our product registers new players on our service, and we've chosen to host it on Azure (we're using .NET) and we wanted it to be stateless (for scalability) and relatively secure.
Since this is the first REST WS I'm writing, I wanted to get some feedback on whether or not it's a solid solution.
Some presumptions to know about our app:
- Users are logged into the service anonymously, without requiring a password from a user
- The WS must be completely stateless to allow horizontal scaling
- We're connecting using HTTPS (SSL) to prevent 3rd party snooping
- We target for native iOS/Android devices
- Our main concern is making sure only non-tampered clients are able to send requests
And the abstract authentication process:
- The client creates a simple hash (UDID:Timestamp) and encrypts it using the timestamp with some basic algorithm (for example, secret key is every 2nd character from the hash)
- The client sends his UDID, Timestamp & hash to the server
- The server rebuilds the hash and decrypts the encrypted hash sent from the user
- If the two are equal - we know that it was actually sent from our client (and hopefully not from a malicious sender)
Any input/suggestions would be great - obviously since it's the first time I'm handling this issue I might have designed it incorrectly.
Reading the security specs for OAuth, it seems that there is no real answer to my question - since the client and server must know the secret keys and the client is locally stored on our users' mobile devices (as opposed to a web app).
From the OAuth security guide (http://hueniverse.com/oauth/guide/security/):
When implementing OAuth, it is critical to understand the limitations of shared secrets, symmetric or asymmetric. The client secret (or private key) is used to verify the identity of the client by the server. In case of a web-based client such as web server, it is relatively easy to keep the client secret (or private key) confidential.
This does not prevent using OAuth within such application, but it does limit the amount of trust the server can have in such public secrets. Since the secrets cannot be trusted, the server must treat such application as unknown entities and use the client identity only for activities that do not require any level of trust, such as collecting statistics about applications. Some servers may opt to ban such application or offer different protocols or extensions. However, at this point there is no known solution to this limitation.