You don't need to get permission everytime from the user if you are going to store it in a DB. The problem with this is that you will have to implement another level of authorization in your site/app, kind of a password for your app, so that when the session times out, or a user comes back again, he can authorize with your site's password and thus you can use the initial access token granted behind the scenes. This way of doing things is against the "Sign in with Twitter" philosophy, but then I also don't see a way of re-using the access token if you are going with "Sign in with Twitter" philosophy. You are going to ask the user everytime (which means a new access token), and after getting a new access token, you are going to do verifyCredentials (to find out who logged in actually)... and verify- credentials is limited to only 15 requests per 1 hour. This seems like using "Sign in with Twitter" and not reusing access token, you can login only 15 times in an hour? I hope this is not correct... but thts what I understand from http://apiwiki.twitter.com/Twitter-REST-API-Method:-account%C2%A0verify_credentials... If my assumptions are correct, 15 wrong verify-credentials requests from your site will halt your site for at least 1 hour .. and another 15 wrong requests for another 1 hour... which seems too easy for your competitors to block your app!! I'd rather add another authorization level in my app than face this...
corrections please!!
