> > Twitter's implementation of OAuth is not up to spec, so they issue > long-lived tokens (that never expire). These can be stored in a database and > reused forever (or until Twitter updates their implementation of OAuth). > Although this has serious security risks, it makes the implementation of a > multi-account solution very easy.
Maybe you are getting OAuth 1 confused with OAuth 2 but the OAuth 1 spec does not define or even recommend how a provider should handle token duration. If I were you though, I would query the access token at the beginning of > each session (as per oauth spec) instead of storing them. At some point, > Twitter is bound to get a lot of bad press for their poor implementation of > OAuth, and I bet the first thing they'll do is switch to short-lived tokens. > It's only a little more effort, and it makes your app future proof. @anywhere uses short lived tokens similar to OAuth 2. You could use the internal authentication mechonism it uses although it is unsupported and could break at anytime: http://blog.abrah.am/2010/09/hacking-twitter-anywheres.html Abraham ------------- Abraham Williams | Hacker Advocate | abrah.am @abraham <https://twitter.com/abraham> | github.com/abraham | blog.abrah.am This email is: [ ] shareable [x] ask first [ ] private. -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
