Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
995 views
in Technique[技术] by (71.8m points)

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

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.

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

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.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...