Best way to create a TOKEN system to authenticate web service calls?

Question

I'd like to create a web service architecture that can be called by various platforms such as mobile devices, winforms applications, iphone, blackberry, you name it. So going with something like WCF and wsHttp binding probably kills this and I would need to downgrade to a basicHttp binding for compatibility.

With that said, I need a system to generate a token on initial login (authentication) and then use this token for all subsequent calls, I guess, to validate the authentication and allow the method to execute.

Anyone have tips or suggestions on how to go about this? 1) Generate a token and what's involved in a secure token? 2) How long is the token good for, some users may use their application for hours and possibly even "sleep" their computer

Thank you for the advice.

Answer 1

You should check out OAuth. It's a standard for API authentication, you can probably just plug an existing implementation into your service.

Answer 2

If you're only using one token which is given by the server on the initial authentication, it can be used for any request if it's intercepted. Your only defense is the expiration time.

Beyond that, it depends on what your implementation options are.

A more secure system is to add a timestamp (and possibly a nonce) to each request, sign that, and include that with each request. It requires that the client handles the authentication credentials, knows the signing implementation, and signs each request.

You could alternately have the server authenticate with each request (which could be done with OpenID) or hand out a number of tokens and re-authenticate when more are needed (which could be done with OAuth). If the client can store credentials, these can be invisible to the user. These are more complex, requiring an encrypted transport such as SSL for some of the interactions, and a client which can speak HTTP redirects and handle cookies or other stored state. The client wouldn't have to know how to sign, but if you can do SSL, you probably don't need the complexity in the first place.

If you don't need to be client-agnostic, you probably want to sign requests.

For signing implementations, examples, and libraries, look at Amazon Web Services, OpenID, or OAuth.

Regarding the token expiration time, it depends on your needs. A longer token life increases the window replay attacks. A nonce makes a token single-use, but requires more state on the server.