How to approach securing webservices? I can think of using one of the two approaches below

  1. sending a user name password in every request for validation
  2. Sending a time based token (GUID or some similar long string)

In the first approach I have to query a database every time in most cases an RDBMS to authenticate a user.

In the second I now make a user name password authentication only once and then return to the user a time based token. All future business requests are authenticated via this token. On expiry this token will need to be recreated by the calling client.

Both approaches seem to have their own pros and cons. Which one would you recommend in which circumstances and what would be your reasons for the same? Perhaps a specific condition where one favors the other.

| improve this question | | | | |
  • would you mind editing the question to expand more on "pros and cons" you mentioned? – gnat May 30 '14 at 12:30
  • 1
    This reeks very much like a Gorilla vs. Shark question. – Bart van Ingen Schenau May 30 '14 at 12:43
  • @BartvanIngenSchenau: in 'vs' situation you are looking at a clear winner. I'm not trying to find one winner here, but trying to understand which one is best suited under what particular condition. Its those conditions that I want to talk about; perhaps someone can talk of a third way as well?... The last para should have made that clear. If it isn't let me know. – user20358 May 30 '14 at 12:59
  • @user20358: I have edited your last paragraph a bit to get it more clearly out of the vs-land. If you don't agree with the edit, you can roll it back. – Bart van Ingen Schenau May 30 '14 at 13:13
  • both look the same to me, but I guess any clarity helps. I've committed your edits. Thanks. – user20358 May 30 '14 at 13:20
  1. Use HTTPS.

  2. Seriously. Use it. There is no point in discussing the security of a web service where any password or token will be passed in plain text from the client to the server.

  3. Prefer a mechanism which is already provided by the framework. For example, WCF allows you to implement authentication very easily, doing all the transport-level hard work itself. So don't reinvent the wheel.

  4. There is nothing wrong in authenticating at every request. Instead of speculating about the impact on the database, measure it, profile it and then take the decision based on actual data.

| improve this answer | | | | |
  • Thanks. I was actually going for security at a conceptual level. assuming of course, all the basic things are done, like putting in https. In WCF you can actually send a user name password in the header or you can send the token. Keeping https in both ways, what would be the justifications of using one over the other? there must be some situation where one way favors the other and vice versa... – user20358 May 30 '14 at 13:05
  • @user20358: I would send credentials at every request to keep the service RESTful and simple, and migrate to tokens if profiling shows that credentials checking becomes a bottleneck. – Arseni Mourzenko May 30 '14 at 15:05

Not the answer you're looking for? Browse other questions tagged or ask your own question.