User Management Standard Practice?

carlmango11

Hey,

I'm working on an Android app for my final year project. The app pulls content from a MySQL database by calling PHP scripts with certain parameters etc. The content comes back as JSON.

My question is about authentication. Right now the web service (that's what I'm calling the PHP scripts - not sure if it's the correct term) is totally open. Anyone can come along and call the scripts with whatever parameters they want.

So I'm wondering - what is the proper way of implementing the likes of an authentication token into the service? This is my current understanding and I've filled in the gaps where I don't know the proper way:

User sends off credentials to the web service. Random string of random numbers and letters comes back if credentials were correct. This string is stored server-side in the DB in the user's row along with a timestamp in a "last_active" column.

This token and user's id is then passed to the web service for all further calls. So say you wanted the content of an article:

getArticleContent.php would be called along with parameters like:
articleId = 55
and then the authentication-related ones:
userId = 432
auth_token="sfef434g675fse"


The script would check the user is authenticated with that token.

Is this the way it's normally done? Even if the call you're making doesn't require a user ID you still pass it along with the auth token to every call just to prove you've been authenticated? Surely this would be heavy on the DB to check for every call but I can't think of an alternative.

I assume then that for extra security you'd have a time-out check too - ie: compare time with last active date/time? Again more load on the DB because that would mean every single web service call would need to update the users last_activity timestamp.

So is this method horribly flawed and if so what would be the standard way employed by every-other-app-in-the-world?

Thanks :pac::pac::pac::pac:

markpb

If you're passing a token, you should consider using SSL to protect it in transit. You should also consider limiting the use of that token to the same IP address that the original authentication came from.

carlmango11

Thanks for the response. I dunno if the separate IP address thing is possible right now. It's just a university project so I don't want to have to set up a second server (I'm just using a blacknight plan at the moment so presumably I would need to set up a second plan somewhere else..?).

The SSL suggestion is one I read about and I'm sure I can implement that later. What I'm thinking about is more whether the scenario above is the correct way.

markpb

What I meant is that's if you connect to the service from PC1 and get a token, PC2 should not be able to pass that token to the service. You don't need a second server or anything like that.

You're solution looks fine to me. I wouldn't worry about the load on the DB, a few calls like that shouldn't have much of an impact unless you have lots of concurrent users. Connection pooling would help a lot though, you don't want be setting up new connections to the DB each time.

carlmango11

Thanks, I understand what you mean about the multiple IPs now - that would be a good idea.

I'm going to look into connection pooling as I've never heard of it.

Thanks a lot for your help :pac: