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:

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?


On Apr 21, 10:57 pm, Ali <> 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 <> wrote:
> > Hey Ali,
> > Out of band / PIN code authentication is just one of the OAuth
> > authentication flows we are supporting. 
> > Cf
> > If your app can handle the full OAuth process, stick to it and forget about
> >OOB:)
> > Arnaud / @rno <>
> > On Wed, Apr 20, 2011 at 10:23 PM, Ali <> 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:
> > > API updates via Twitter:
> > > Issues/Enhancements Tracker:
> > >
> > > Change your membership to this group:
> > >

Twitter developer documentation and resources:
API updates via Twitter:
Issues/Enhancements Tracker:
Change your membership to this group:

Reply via email to