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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…