Our request for xAuth was denied. What could be the reason?

[character_works]

Yesterday, I sent a request for xAuth authentication for our application, but I received a reply today that said it was denied. Can anyone here help me understand why?

Here are the details:

Our application is called CharacterWorks. It is a high-end broadcast graphics application. One of the main features of this desktop application is to display tweets as part of live, real-time on-screen graphics for broadcasters such as TV Channels or Webcasters. Our Twitter UI basically connects to the search endpoint of the Twitter API and retrieves user names and tweets for display in broadcast graphics elements such as lower-thirds or crawls.

So, in a nutshell:

1. Our application (CharacterWorks) IS a desktop application that runs on Windows, it is NOT web-based.
2. The application does NOT have immediate access to a web browser.
3. The application is NOT a single-user application, it is used by a number of users around the world.
4. Our application needs to have custom login for each user to so that Twitter API search requests can be sent on a per-user basis. Until now we have been using application-only authentication, but with a growing user base, we should hit the rate limits, soon.

In the light of the information above, it should be clear that our application has no recourse but to utilize xAuth. Why has Twitter denied our application for xAuth access? Could it be because of political reasons (i.e. company located in Turkey?).

More info can be found in our website at http://www.chrworks.com/ . Our company information can be found in http://www.chrworks.com/company and shows a partial list of clients from all around the world.

Any help would be greatly appreciated.

[andypiper]

We can’t comment on individual applications or requests like this here in the forums, I’m afraid. The best thing to do would be to respond to the policy team via email to continue the discussion and to see if there is a way to move the process forward in your specific case.

One thing I will add here is that from a policy perspective, we strongly discourage and seek to avoid the use of xAuth for any applications now. This is because we really don’t want users to be directly sharing their credentials with applications, as that is obviously not good for the security of their accounts. Even a desktop-based application should be able to perform an OAuth flow (I think e.g. both Tweetinvi and LinqToTwitter which are both popular Windows / .NET API clients have support for this), and we are moving towards Fabric for mobile where we have Sign in with Twitter built in to the SDK.

That said, there are still a few edge cases where xAuth may be required/applicable, and the platform support / policy team should be able to help in those situations.

[character_works]

Andy, thank you for the response.

First of all, from our experience with the Twitter policy team so far, it does not look like it will be possible to continue discussion via e-mail, because it simply does not seem like there is an intelligent human being on the other end of the “line”, I am sorry to say. Let me explain, with a brief account of our interaction with the API team:

First, we filled in the form to request xAuth access, explaining the situation as I did here in my original post. Then we got an e-mail, telling us to reply with the exact same information already in the form via e-mail! We sent the e-mail. A day later, we got an e-mail saying “We do not provide technical support through this helpdesk”, which has nothing to do with our request! Then we responded to that, and within minutes we got a standard response refusing our application, with absolutely no explanation whatsoever.

There is definitely room for improvement here, don’t you think?

Regarding your comments about oAuth, I understand and appreciate the issue of protection of user credentials. And yes, it is technically possible to use oAuth instead of xAuth. However, in our case, it affects the user experience quite badly, since it will mean that users will have to go through the Twitter login page each time they work with the application, not to mention the rather large and unnecessary overhead of embedding a web browser into our application.

Even without considering these points, using oAuth in a desktop application does not seem to have any real security benefit compared to using xAuth in terms of user credentials, because, simply put, how difficult would it be for a desktop app to sniff keypresses to retrieve usernames and passwords entered in a web browser? Whatever the application and authentication method, entering user credentials must take place at the discretion of the users themselves, and if they do not trust the application, they should not enter them.

Furthermore, in the specific case of our application, users are technical people (broadcast professionals), and the application requires a basic level of training, and it is a relatively low-volume application, with total user count in the thousands range. While the application is relatively new (about 2 years old), the company is much older and reputable.

Please feel free to enlighten me if I am missing something here. I am really trying to wrap my head around the reasoning behind our application being refused, but I am unable to.

[andypiper]

I’m sorry for your experience using the support form - we are aware that this has room for improvement, and we hope to be able to bring changes in to that area soon.

I don’t see that the OAuth alternative is particularly problematic based on what you’re describing - it is very straightforward to pop open a web view, and potentially to use PIN-based authentication. There’s no reason to go through that authentication every time, once you’ve got a token you’re fine to cache it (at the user’s discretion) and they can de-authorise the app from their account at any time.

Again, I can’t help directly with a policy question of this kind here, except to say that we have a desire to avoid granting xAuth permissions to any new apps unless absolutely necessary - feel free to circle back with the Platform Operations team via the email channel you have open, I can assure you that there are very capable folks on the end of the forms and emails you’re using.

[character_works]

Actually, we were not aware that the tokens did not expire. We thought that the tokens expired on their own (and probably quite frequently), so the users would have to enter their credentials through the web browser each time that happened. If the application were allowed to save user credentials, that would be avoided. Later, we found out that the tokens did not expire, so that greatly alleviated the problem. At least, the platform operations team could be helpful in realizing this by engaging in a e-mail discussion, but that seemed and still seems unlikely to happen.

In the end, we “solved” the problem by biting the bullet and embedding a web browser view in the application. I still think it is a rather poor experience for the user to have to go to a browser popup that has nothing to do with the app itself (and the pin-based auth is even worse). Thank you for your replies, anyway.