[twitter-dev] Re: Unexplored Dark Underbelly of OAuth
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.
Re: [twitter-dev] Re: Unexplored Dark Underbelly of OAuth
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 Team http://twitter.com/raffi
[twitter-dev] Re: Unexplored Dark Underbelly of OAuth
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
Re: [twitter-dev] Re: Unexplored Dark Underbelly of OAuth
we can argue this back and forth all night, however, i will agree from a developer's perspective that implmenting an api key would be trivial - but i will completely disagree that the user's perspective will be simple. i think there is complex messaging involved, and requires that the developer implement a good workflow that is not confusing to the most naive users. i think that characterizing it as a simple cut and paste is vastly oversimplifying the interaction. instead, i would say that an oauth web workflow, especially in the case that the user is already logged into a twitter.com session, is significantly easier. but, like i said, we could argue this back and forth all night, so, instead, i'm going to choose to go get dinner :P On Thu, Dec 10, 2009 at 7: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 -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: Unexplored Dark Underbelly of OAuth
The user still has to be shunted between browse and app to generate
a new api key
then paste it over. Having to manually copypaste 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
[twitter-dev] Re: Unexplored Dark Underbelly of OAuth
Yeah, I agree about dinner. Besides, this will be a moot point when Google buys Twitter (http:// bit.ly/8x9o6z) because then we will all have to switch over to Google Account logins for Twitter. On Dec 10, 11:16 pm, Raffi Krikorian ra...@twitter.com wrote: we can argue this back and forth all night, however, i will agree from a developer's perspective that implmenting an api key would be trivial - but i will completely disagree that the user's perspective will be simple. i think there is complex messaging involved, and requires that the developer implement a good workflow that is not confusing to the most naive users. i think that characterizing it as a simple cut and paste is vastly oversimplifying the interaction. instead, i would say that an oauth web workflow, especially in the case that the user is already logged into a twitter.com session, is significantly easier. but, like i said, we could argue this back and forth all night, so, instead, i'm going to choose to go get dinner :P On Thu, Dec 10, 2009 at 7: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 -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi
