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 m.twitter.com. 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 <m...@twitter.com> writes: > 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.
Let me make sure I understand the proposed flow correctly:
1. Application uses consumer key/secret to get request token, sends user to Twitter authentication page. 2. User authenticates with Twitter and authorizes application. 3. Twitter gives user PIN number which they then enter in to the application. 4. Application uses PIN and request token to get access token and proceeds as normal with OAuth-authenticated requests.
With this setup, will users be able to authenticate multiple instances of the same application? If so, it might be useful to allow the user to optionally assign a name to the application instance, so long as that doesn't make the user experience too confusing.
- Michael
-- mouse, n: A device for pointing at the xterm in which you want to type. Confused by the strange files? I cryptographically sign my messages. For more information see <http://www.elehack.net/resources/gpg>.
I wanted to follow up on this. Admittedly, I'm a newb with oauth.
I'm currently working on an application that uses MS's cloud computing
environment Azure. I'm using this to schedule tweets in the future.
Azure has a worker role which is an application that a web user never
directly works against. The worker role is being used to post updates
to a user's stream. Right now, I am using basic auth, but I would
like to move to oauth. My current design has the user storing
twitterids and passwords in a table. The user interacts over the web
with the webrole and then the worker role handles the posting.
It looks to me, given a VERY limited knowledge of oauth, that its
designed with user interaction in mind. Does that sound correct?
Hi Wallace, http://www.Twollo.com does something similar to what you are describing (it hosted on the Google App Engine). You can store the users oAuth token secret, access token (and request token if you don't have the access token) and then use these at a later date to send authenticated requests to Twitter. The good thing is that once you have the access token it is unlikely to expire (unlike a users password) unless the user revokes access to your application.
Admittedly there is some user interaction, but it is only at the start of the process, much like the current process of asking for a users username and password. Once it is all done it is easy to make authenticated requests to Twitter without any user intervention.
This thread is mainly about the changes that were made to support desktop applications, but again, once the access token has been received the same applies as mentioned earlier.
> I wanted to follow up on this. Admittedly, I'm a newb with oauth. > I'm currently working on an application that uses MS's cloud computing > environment Azure. I'm using this to schedule tweets in the future. > Azure has a worker role which is an application that a web user never > directly works against. The worker role is being used to post updates > to a user's stream. Right now, I am using basic auth, but I would > like to move to oauth. My current design has the user storing > twitterids and passwords in a table. The user interacts over the web > with the webrole and then the worker role handles the posting.
> It looks to me, given a VERY limited knowledge of oauth, that its > designed with user interaction in mind. Does that sound correct?
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.
> 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 > m.twitter.com. 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.
> Thanks; > – Matt Sanford / @mzsanford > Twitter Dev
Would it be possible to make the last number of the PIN a mod 10 checkdigit? This would allow applications to validate the PIN without having to do a hit to the oAuth webservice, say in the case that the user accidentally missed one of the digits when copying them from the page, or perhaps the user tried to memorize the number and entered it incorrectly.
> 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 > m.twitter.com. 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.
> Thanks; > – Matt Sanford / @mzsanford > Twitter Dev
|
