2

I'm implementing a rest api to using the new web api framework. This api will be consumed by other companies so we'll be adding an authentication method.

In relation to authentication, I'm thinking to implement something based on tokens. Something like this

  • client provide credentials to login method
  • system authenticate client and send a token
  • client uses this token on following api calls

I wonder if this schema is useful for my scenario. Operations will be mainly atomic, basically clients will periodically ping this api to get some specific data, so not sure if make sense having a session token (at some point the token should expire and not sure how to manage this).

How would you recommend to implement authentication schema for this scenario?

StackOverflower
  • 5,463
  • 13
  • 58
  • 89
  • Take a look on this, using HMAC authentication: http://stackoverflow.com/questions/11830338/mvc-4-web-api-creating-api-keys/11831391#11831391 – cuongle Aug 09 '12 at 15:58

2 Answers2

2

When you generate a token I would store it in a database with a foreign key back to the authenticated login's primary key. I would also (with the token) store the date and time it was established, and a timeout period (you could set this per token, or store it in a config). Check the token/time everytime the service is pinged by that user, then force them to reauthenticate after that time expires (by checking it against the created date stored with the token).

This would make sure that the login information is only getting transmitted after the token expires, when a new token is generated it would delete the old token record.

Am I understanding your requirements right?

Jeff Turner
  • 1,318
  • 8
  • 12
1

Making a token based authentication scheme like this is not easy.

I don't really have an answer for how you could implement it in a good and secure way. But will offer some thoughts off the top of my head about issues you will have to deal with:

  • The token generation need to be well randomized and the tokens need to be "sufficiently" (for some definition of sufficient) long in order to prevent someone from simply sending a bunch of different tokens to see if he "gets a hit"

The above issues should not be too difficult to implement. But the more tricky thing to figure out is:

  • How you can you reliably verify that the token has not been "kidnapped".

If the token is simply some random string, then anyone who happens to "see" it in tranfer (use SSL) will be able to assume the identity of the use for which the token was generated.

The token, when received by your service will let you know that:

  • Your application issued the token to user/application/entity X
  • The token is intact (has not been changed)
  • Any other thing you store with the token (is it expired etc)

But it will not without further effort let you know for sure that it was sent by user/application/entity X. It could be Y who has managed to get hold of the token.

That is the case for many authentication schemes of course, so depending on just how sensitive your data is, and also on what kind of operations can be done via you service, it may not be a huge issue for you.

user1429080
  • 9,086
  • 4
  • 31
  • 54