Apologies for the lack OOB explicit documentation -- it's heavily documented elsewhere on the web and for the most part follows the exact same OAuth 1.0A flow, with the exception of the callback step.
oauth_callback=oob should ONLY be passed to the request_token step of OAuth -- it's invalid to send it to any other end points of OAuth (as of OAuth 1.0A) -- it's not accepted on the authenticate or authorize pages because there's no way to validate the application set the callback (versus a malicious man in the middle). Brief instructions: 1. set your app to desktop mode. 2. issue a request for a request token, including oauth_callback=oob as one of your parameters 3. once you have the request token, build your link to the authorize page, including only the oauth_token parameter (corresponding to the request token) 4. the user will be shown the oauth_verifier / PIN code. 5. ask your user to enter the PIN code, collect and store it temporarily in your app 6. submit a request for access token, including the PIN code the user gave you as the value for oauth_verifier In non-out of band flow, the only difference here is that the value for oauth_callback is an explicit URL instead and the oauth_verifier is given to the application on the callback phase rather than being collected by the end-user. Hope this clears up the flow for you. You can keep your application marked as a client mode and still use oauth_callback=oob, but you can't use dynamic callback URIs with mode=desktop. Even if you've stored a default callback URL or implicitly want to do OOB OAuth, I recommend to always always always send an explicit oauth_callback on the request token step and never rely on any implicit value that may be stored in your client record. Taylor @episod <http://twitter.com/episod> - Taylor Singletary On Thu, May 5, 2011 at 3:00 PM, Dave Florek <dflo...@gxlinc.com> wrote: > > Thanks for bringing this up, Ali. > > As far as the link for more #oob info, documentation on the OOB flow > has apparently been "in the works" for almost two years now (I found > it mentioned in a post from June 2009), so I naturally have some > concerns as to how big a priority it is at Twitter. > > I'm trying to integrate the OOB flow into a desktop client as well, > and running into a situation where, now that our company has > registered a browser-based app with a default oauth_callback url, the > OOB pincode flow does not appear to be honored at all. With the > limited amount of information available, I would expect the following: > > > https://api.twitter.com/oauth/authorize?oauth_token=o1hiPRbH7pYeWuVAV3D0JlcZikr9NshjXXXXXXXXXXX&oauth_callback=oob > > to produce a twitter-hosted page displaying the pincode, even though > our company has registered a browser-based flow with a default > callback. I.e., it seems like the provided oauth_callback value > should override the default one. For what it's worth, we have brower- > based functionality and a related desktop-application, and would > prefer not to have to register both as separate "applications", if > instead we could have each of them interact with the Twitter API in > the manner best suited to it. Is this even remotely possible? > > Thanks, > Dave > > > On Apr 21, 10:57 pm, Ali <t.alra...@gmail.com> wrote: > > Full OAuth is not possible for desktop/mobile apps which is what I am > > implementing. > > The issue is this. After authenticating a request token a verifier is > > supplied by Twitter to verify that the user allowed access. There are > > a couple ways to send this verifier code back to the app. > > > > 1. For web apps, Twitter redirects to a developer supplied URL with > > the verifier added in the query string. The app can easily grab the > > verifier and use it in the request to exchange the request token for > > an access token. > > > > 2. For desktop/mobile apps, there is really no good way to send it > > back. Twitter offers theooboption which gives the user a pin number > > that they would have to enter into the app. This pin acts like the > > verifier. > > > > What I am seeing is that this last step of getting the verifier is not > > necessary. I am able to exchange the the request token for an access > > token after it has been authorized by the resource owner without > > passing the verifier pin. > > > > What I want to know is whether this is a bug or temporary behavior or > > this is the expected behavior. The verifier is really not that > > essential because Twitter already knows the user has authorized the > > app. The verifier more allows the app to continue with the process of > > authentication. > > > > I would like to hear from the Twitter dev team on what the long term > > plans are in regards to the verifier. Is it okay to ignore the > > verifier for desktop/mobile apps? It is working without it anyway. > > > > Thanks, > > @talrahem > > > > On Apr 21, 8:35 am, Arnaud Meunier <arn...@twitter.com> wrote: > > > > > > > > > > > > > > > > > Hey Ali, > > > > > Out of band / PIN code authentication is just one of the OAuth > > > authentication flows we are supporting. Cfhttp:// > dev.twitter.com/pages/auth_overview > > > > > If your app can handle the full OAuth process, stick to it and forget > about > > >OOB:) > > > > > Arnaud / @rno <http://twitter.com/rno> > > > > > On Wed, Apr 20, 2011 at 10:23 PM, Ali <t.alra...@gmail.com> wrote: > > > > Hi, > > > > > > I've been experimenting with OAuth authentication with the Twitter > API > > > > for desktop/mobile apps and found out that the verifier pin is not > > > > necessary. Once the the request token is authorized, I am able to > > > > exchange it for an access token without providing the pin code. > > > > > > Is this the official expected behavior? I couldn't find any info on > > > >OOBin the API documentation. It is just barely mentioned and the link > > > > for more info doesn't work. > > > > > > Is there any documented behavior regarding the verifier pin and > > > > whether requiring the user to enter the pin is recommended or > > > > required? > > > > > > Thanks > > > > > > -- > > > > 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 > > -- > 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 > -- 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
