Can we change the wording on the PIN page of the desktop workflow? Currently it is worded as follows:

You've successfully granted access to <ApplicationName>!
Enter the following PIN when prompted by <ApplicationName>

Obviously a desktop application has no idea that this flow actually completed, and hence has no way to "prompt" the user to do anything. A user could sit there for awhile waiting for a prompt.

I think it would be more clear if it was worded something along the lines of:

You're almost done pairing <ApplicationName> with your Twitter account!
Simply return to <ApplicationName> and enter the following PIN to complete the process.


Matt Sanford wrote:

One of the things we've been saying about OAuth all along is that we'll be improving the desktop application experience. Well, the time is here for the first re-visit. As part of out changes for OAuth version 1.0a [1] I have been looking at how this is going to work and there is going to need to be a change that will not be backward compatible. Some of this is already coded and waiting to go, and some of it is in-progress. I expect we will deploy this the end of next week or the beginning of the following one in order to allow you to have a minimum of 7 days to make changes. These only effect desktop applications so the majority of OAuth applications are not affected. Here are the expected changes:

1. If your application is registered as a desktop application callbacks will not be supported.

*Workaround*: Visit your application details page to change the application type and provide a default callback URL. *Details:* Dynamic callbacks are currently disabled for all applications. With changes for 1.0a [1] will re-enable dynamic callback support but applications registered as 'desktop' will not support this. When requesting a request token the you will get an error saying that callbacks are not supported in desktop applications. This is to prevent stealing of tokens created with a PIN (see #2) by webapps re-using the freely available desktop consumer key and secret.

2. If your application is registered as a desktop application there will be a PIN the user must enter in your application

* Details*: In the current code desktop applications end in a dead-end page. This new flow will give the user a PIN that they enter in the application and that must be provided to swap a request token for an access token. This will help secure tokens for desktop applications since the security of the consumer key and secret cannot be relied upon. *Feedback: *We are planning to make this a required step but I am open to discussion if anyone feels there is a compelling case for desktop applications without a PIN. Email me directly with feedback.

3. If your application is registered as a desktop application you will not be able to use the 'Sign in with Twitter' functionality.

*Details:* 'Sign in with Twitter' requires a callback URL which will not be allowed per #1 above.

We're working to make sure we provide OAuth interfaces wherever possible. Desktop applications was a definite problem that needed some fixing. Close behind that is mobile web which is currently being looked at by a group reviewing all of If you have any objections to the changes above, or some reason that you don't think it will work, please feel free to email me directly.

 – Matt Sanford / @mzsanford
     Twitter Dev

[1] - OAuth spec 1.0a addresses problems with oauth_callback and should be finalized very soon. More info at

Reply via email to