> 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

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:

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: 

Reply via email to