2

I am developing native mobile client for store that requires user authentication in order to make purchases available.
I have my web store page, authentication is provided by CMS (OpenCart).
Now I need to implement secure and robust login on mobile devices.
I am using REST API for getting data public data from web site (products, sales ....).
But what is the best choice if I need to provide secure connection between native mobile client and my web server.
I am using "native" to notice that there is no web view or something similar in the app.

There a lot of similar app from popular online stores ( Ali,Ebay, Amazon) all these app use authorization without browser built in mechanisms, I wonder how do they implement this.

What are possible ways to secure user important actions in native client.

Of course I have read a lot of about this, but there no one good solution as well as any article describes available approaches.

Please suggest what is the secure, robust and not very difficult way to do this.

I am grateful for any help in advance.

1 Answer 1

2

Without understanding more of your app, there are many correct answers to this question.

One common strategy is to use username/password to authenticate to your API. On successful authentication your API will create and return an auth token. Your app will then pass the auth token on each subsequent call.

The typical format of an auth token is

username + other data + HMAC(user + data, secret known only to the server)

When your server receives the auth token on a subsequent call, it parses the username and the other data (whatever you may want to store), performs the HMAC, and then compares it with the HMAC in the token. If it matches then you have a valid login, otherwise you log the attempt and abort.

This strategy allows the server to be stateless as any important information can be stored in the auth token. If you need to maintain a session on the server, you could use an auth token of the format:

session ID + HMAC(session ID, secret known only to the server)

You probably want the session ID to be a secure random number and not a counter or memory pointer as you don't want the client to be able to guess other session IDs even though the client can't forge the token without the secret.

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .