Twitter OAuth token storage without user database?

I'm attempting to throw together a pretty quick mash-up that I think would be useful for folks, and I'd like to make use of Twitter communication. This is my first experience with OAuth, and I've chosen the Twitterizer library to get the job done.

My question comes from the fact that I don't plan on storing user information or having users create accounts (it's meant to be more of a quick utility). Given this, once I get the user's OAuth access token and secret, I have to figure out a secure way of storing them (likely locally) without compromising the security principles of OAuth.

Here's what I'm thinking so far:

• User goes through the process, u开发者_C百科p until I have their access key and secret
• I encrypt the values and store in a cookie to retrieve later

However, a few questions / concerns:

• What (if anything) prevents someone from impersonating a user via the cookie?
• What is the correct way to deal with potentially multiple users on the same browser? My initial thought is a "logout" button on my app that would kill the cookie, but I'm not sure.

Thanks in advance for any help you can give!

---

I do not know much about OAuth since I don't use it, but one way you could handle multiple users on one browser is to use some kind of timer function. Each time the user connect's to your page the cookie get's a "Valid until" timestamp wich is now+30 minutes for example. If the valid until time is passed the application will ask the user to re-authenticate themselves.

You could even do this by setting a very-short timestamp on page unload and then set a longer on pageload. This will mean that if the user goes from one page to another within your app they will have a long time-out, but if they leaves your app the next user could use the same browser within a minute or so without the previous user logged in.

A more secure way could be to to use sessions. You could set a cookie that holds a session ID for example and then set the "valid until" values in the session.

Be aware however that these methods are definitely not foolprof since the cookies can be manipulated, the timestamp changed and sessions highjacked.

---

I think on the whole, cookies shouldn't be relied on for sensitive information, but, security is always a balancing act. Ultimately, you're trying to obscure the information you are storing insecurely.

In addition to encrypting the token, you could also include a checksum. I'd keep it in a separate cookie. It needs only to be some value that your site can use to verify the integrity of the sensitive data, to ensure it wasn't tampered with. It could be a one-way encrypted hash or something like that.

You can also specify an expiration date on the cookie. Perhaps keep it to a few days, or weeks.

I'll say this again, generally storing sensitive information in a cookie is a bad idea.