Reputation: 29925
I have done a lot of research and I can't work out if this is the best way to achieve what I need.
I have a generic web app and I want to create a generic mobile app to go with it. In order for users to save data/access user specific data/etc they have to log in and the login has to be authenticated over my web app's REST api.
So the api has a private and a public key for the mobile app. The public key tells me where the request is coming from (the mobile app) and the private key is used as a "salt" to hash the query string which can then be rehashed on the web server when the request comes in and compared for validity.
To log in the user enters their username and password which is then sent as query string vars as per the method above. The query is checked for validity at the other end and the username+password pair is checked against the database. If the login is correct a random "auth token" is generated for that user and the public key and sent back to the mobile app for storage locally on the device.
When the next request comes in from the mobile app one of the query string variables is the "auth token" from earlier which is checked for validity (with the app's public key) against the "auth tokens" table in the database. If it is valid then do the request.
My question here is, have I got this right? Is this the best way to achieve what I need? The last step seems really insecure as both the public key and the auth token will be visible if the request is intercepted. Obviously the request will be checked against the hash of the query string and the private key at the other end and this will make sure the request isn't coming from anywhere malicious.
Are there any other steps, or things I've missed which would be useful? For instance I was reading that there should also be a timestamp variable which should be checked against a 5/10min time frame in the request. Any timestamps older than 5/10 mins and the request should be rejected. Is this important?
Thank you.
Upvotes: 2
Views: 2140
Reputation: 6941
What you are describing is basically a homebrew version of 2-legged OAuth. There are many implementations out there that you can basically use. Whenever it comes to security related stuff, I go by: If others have already done it, don't reinvent the wheel. OAuath is used by many big sites out there (Twitter, Facebook, GitHub, Google, ...) and they have done a lot of research that went into the OAuth standards. So I'd suggest to use those.
If you are concerned that messages you send may be intercepted, you should use HTTPS... Which is a good idea in general, if you are passing around username and password combinations over the wire.
Upvotes: 2