The user still has to be "shunted" between browse and app to generate
a new api key
then paste it over. Having to manually copy&paste a key on a device
that does not support clipboards
would be very UX unfriendly. Hey remember this 40 char random string
to type back into the app. Yeah users
won't do that.
With the upcoming support to exchange basic auth credentials for an
oauth token will help improve
the UX. The user when they first use the app just provide their
username and pass. Then the application
makes a HTTP request to exchange those for a token and then it ready
for action. The oauth token acts much like
an API key. No copy & paste needed. A good twitter library can
automate this process for the developer.
SomeTwitterLibrary.get_token('username', 'password')
Then just store that away for later use. Not much harder than basic
auth when you bypass the 3 legged oauth dance.
As for the consumer keys I propose a method to dynamically request
from twitter a new consumer key/secret. The first time
an application launches it will send a request to twitter registering
itself. Each computer/device will then have an unique
consumer key & secret to use for signing the oauth requests.
Josh
On Thu, Dec 10, 2009 at 9:05 PM, Dewald Pretorius <dpr...@gmail.com> wrote:
> Raffi,
>
> True, but then require each application to send its own API Key along
> with each request. That API Key can be issued on a page where you
> register an application with Twitter.
>
> Yes, I understand that brings us back to the issue I raised in my
> first post.
>
> But, from a user experience, it is exponentially simpler than the
> OAuth workflow, and for a developer it is also exponentially easier.
> It's simple copy and paste for the user as opposed to being shunted
> back and forth in a browser, and it requires virtually no additional
> coding for a developer. And for Twitter, you can still identify the
> app, and you have all the control you have with OAuth.
>
> It's a simple yet very effective solution.
>
> On Dec 10, 10:50 pm, Raffi Krikorian <ra...@twitter.com> wrote:
>> it all comes down to being able to associate an action with an application.
>> having a single API key would then require a user to unauthenticate all the
>> applications they are using, rather than removing access to a single
>> application. the inverse of this is that twitter then has the ability to
>> tell a user "this application is the one that sent a DM from you without you
>> knowing it" -- the user can then revoke access.
>>
>> so, i would disagree that a single API key would cover all the security
>> benefits of OAuth from the user's perspective.
>>
>> i will admit that that this is a hard problem, and this relies on an
>> application keeping the tokens in a secure fashion -- however, there are
>> still benefits over the current system of basic authorization.
>>
>> I still don't understand why Twitter doesn't just simply give each
>>
>>
>>
>> > user a unique 40-character API Key, which they can provide to an app
>> > instead of their Twitter username and password.
>>
>> > With that:
>>
>> > a) The user's Twitter login credentials are not shared with anyone;
>>
>> > b) The user can generate a new API Key, which immediately invalidates
>> > access to all apps that don't have the new key;
>>
>> > c) Changing the Twitter username and password does not break existing
>> > app access;
>>
>> > d) It's practically impossible to brute-force a 40-character key.
>>
>> > It covers all the security benefits of OAuth from the user's
>> > perspective. The only downside would be Twitter's control over
>> > applications that they would gain with OAuth.
>>
>> --
>> Raffi Krikorian
>> Twitter Platform Teamhttp://twitter.com/raffi
>
