[twitter-dev] Re: Is the verifier pin required in OOB?
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=o1hiPRbH7pYeWuVAV3D0JlcZikr9NshjXXXoauth_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
Re: [twitter-dev] Re: Is the verifier pin required in OOB?
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=o1hiPRbH7pYeWuVAV3D0JlcZikr9NshjXXXoauth_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://
[twitter-dev] Re: Is the verifier pin required in OOB?
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 the oob option 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 OOB in 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
