0

Legacy SOAP service here at work use a token authentication. The flow is:

As first step I call the startSession method passing username (say myUser) and password (say myPWD) as parameter. At this point username/password are checked against a DB table:

  +------------+-----------+---------+
  |  username  | password  |  token  |
  +------------+-----------+---------+
  |   myUser   |   myPWD   | (null)  |
  +------------+-----------+---------+

Since username/password matches a token is generated, stored in the database (at the same row where username and password are stored), and returned to the user that can use it for next calls:

  +------------+-----------+---------+
  |  username  | password  |  token  |
  +------------+-----------+---------+
  |   myUser   |   myPWD   |  myTok  |
  +------------+-----------+---------+

Right now, user myUser can call any method of the service simply passing a token. Both username and token are checked, if it matches the method continue, a new token is generated, stored in the DB and finally returned to the user for a new call.

I hate this behaviour and I'm searching for a more reliable approach. I would: - Do not store (fully) token in a database - Do not use external library (unless it is a really minimal library) - New token for every method calls

Any ideas?

  • Is the token preventing replay attacks against the web service? This approach is one that I've seen in secure coding guidelines. What don't you like about it? What problems are you encountering? – user40980 Oct 2 '14 at 15:01
  • Is it safe to store the token that will authorize you on a database? Does this store/retrieve mechanism affect the performance? – BAD_SEED Oct 2 '14 at 15:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.