I agree with Isaiah. This is a huge improvement over the current PIN
workflow.
When will this roll out? Is there an authorization endpoint we can use
now for testing purposes? That would be great.
On Dec 10 2009, 8:58 am, Isaiah supp...@yourhead.com wrote:
This seems like a dramatic improvement
On Fri, Dec 11, 2009 at 04:03:01AM -0800, Duane Roelands wrote:
It seems clear to me from Raffi's
comments on it that this third oauth flow is intended solely to enable
Twitter use from embedded applications or in other environments in which
it is not possible to use the existing oauth
Couldn't agree more. If this is true, it's time for me to say goodbye.
On Dec 10, 11:40 pm, Duane Roelands duane.roela...@gmail.com wrote:
Many of us in the developer community have been strongly pushing the
point of view that third-party apps should never be asking for user
credentials. We
It seems clear to me from Raffi's
comments on it that this third oauth flow is intended solely to enable
Twitter use from embedded applications or in other environments in which
it is not possible to use the existing oauth flows because there is no
way to bring up a browser.
And this will be
Also if you're going to make changes to oAuth and the way it works
currently... please bear in mind many of us already have production
apps using oAuth.
Maybe you could move the oAuth to versioning to allow us time to move
to newer methods as and when you release them?
On Dec 9, 7:46 pm, Duane
we're not making any fundamental changes to oauth - your apps should
continue to work fine.
the changes that we are making involve implementing
http://tools.ietf.org/html/draft-dehora-farrell-oauth-accesstoken-creds-00#section-4.
this will allow applications to obtain oauth tokens for a user
Does that mean the PIN work flow will go away?. The given below approach
may be fine with console based/browserless apps. But i would still prefer
the the PIN based workflow for desktop apps (which can invoke browser for
authentication) as users do not prefer sharing their passwords.
On Thu, Dec
i do not believe we are deprecating the pin workflow, we are adding
another option.
Does that mean the PIN work flow will go away?. The given below approach
may be fine with console based/browserless apps. But i would still prefer
the the PIN based workflow for desktop apps (which can invoke
On 12/10/2009 6:22 AM, Raffi Krikorian wrote:
we're not making any fundamental changes to oauth - your apps should
continue to work fine.
the changes that we are making involve implementing
http://tools.ietf.org/html/draft-dehora-farrell-oauth-accesstoken-creds-00#section-4.
this will allow
Me too.
Don't know if there is any compelling reason on twitter to allow third party
apps send username/password for oAuth. FriendFeed is also allowing this.
Now All those thirdparty apps who already store username/passwords (for
Basic auth) and those who use other third party servies like
John Meyer wrote:
okay, forgive me if I'm wrong, but wasn't the whole point of oAuth
that the application didn't need to know the username/password? That
the user would grant access to the application and then the
application would store that rather than the actual
username/password. Or am
@ michael
The web case is different - a web site doesn't have the user's credentials
unless they explicitly provide them.
With the new oAuth implementation even web apps will be allowed to collect
user's credentials. There is no way to enforce webapps to delegate
authentication
On Thu, Dec 10,
precisely.
in a web scenario, developers are encourage to go through the web
workflow - this new workflow is for those environments where bringing
up a browser is impossible (embedded devices), cumbersome, or would
destroy the UX experience. i would love to see developers message to
their users
don't be evil. in a web scenario, send them to twitter.com for the
oauth workflow. in the case that you can't do that, do not store the
username and password - simply pass them through and store the tokens
instead.
*And* reinforce to users that 3rd party web services should use OAuth, not
This seems like a dramatic improvement to me. When will Twitter start rolling
out support for this, I'd like to be ready with something on github for this as
soon as it lands.
Isaiah
YourHead Software
supp...@yourhead.com
http://www.yourhead.com
On Dec 10, 2009, at 5:22 AM, Raffi
Raffi,
Can this method be used to migrate users from a Basic Auth app to an
OAuth app?
Wouldn't it be great and so much easier if I could migrate all my
users, for whom I already have the username and password, with this
method. I can do that in one afternoon.
Dewald
On Dec 10, 11:42 am, Raffi
hi dewald.
that's one of the design goals, so yes :P
On Thu, Dec 10, 2009 at 9:25 AM, Dewald Pretorius dpr...@gmail.com wrote:
Raffi,
Can this method be used to migrate users from a Basic Auth app to an
OAuth app?
Wouldn't it be great and so much easier if I could migrate all my
users,
Raffi - can someone at Twitter PLEASE comment on the delegation question? If
your app uses the web oauth flow, as strongly recommended by Twitter and
reiterated in your statement below, how do you see consumption of 3rd party
APIs happening when you don't have the user's un/pw? I don't understand
we're not unwilling to answer the question. it is something we're actively
working on, and we're just not in a state to release anything yet.
On Thu, Dec 10, 2009 at 9:52 AM, Michael Steuer mste...@gmail.com wrote:
Raffi - can someone at Twitter PLEASE comment on the delegation question?
If
Great to hear it’s on your radar and you’re actively working on it. Any
chance you’ll involve the dev community prior to presenting the solution as
a fait-accompli? And do you have an idea around timing for this solution?
yes, and no. :P
On 12/10/09 9:55 AM, Raffi Krikorian
Many of us in the developer community have been strongly pushing the
point of view that third-party apps should never be asking for user
credentials. We did so because we believed that Twitter was firmly
committed to the security of the ecosystem and protecting the accounts
of its users. It now
I agree with Duane... A lot of us have implemented oAuth on Twitter's strong
urging and continue to be punished for it by none other than Twitter... Of
course consumers will prefer clients with the easier log in flow, giving
unfair benefit to apps that just request the un/pw instead of redirecting
Apps that provide an API should implement their own API authentication
scheme.
In all honesty, I do not think it should be Twitter's problem.
An app can very easily provide the user with a unique API key, such as
the one used by bit.ly and FriendFeed (initially), that your user must
enter in
Duane Roelands wrote:
There was a great opportunity here for Twitter to be a security leader
in the social network space by saying We don't want our users giving
their Twitter credentials to anyone except Twitter. It's a shame
they didn't stick to their gun; the result is going to be a less-
On Thu, Dec 10, 2009 at 07:33:28AM -0700, John Meyer wrote:
okay, forgive me if I'm wrong, but wasn't the whole point of oAuth that
the application didn't need to know the username/password? That the
user would grant access to the application and then the application
would store that
On Thu, Dec 10, 2009 at 10:40:20AM -0800, Duane Roelands wrote:
Many of us in the developer community have been strongly pushing the
point of view that third-party apps should never be asking for user
credentials. We did so because we believed that Twitter was firmly
committed to the security
On Fri, Dec 11, 2009 at 00:53, Dave Sherohman d...@fishtwits.com wrote:
- If oauth is the only allowed authentication method, a rogue app would
not be able to gain full access to your account. Perhaps most
importantly, it would not be capable of changing your password and
locking you out.
On Fri, Dec 11, 2009 at 01:27:48AM -0600, Abraham Williams wrote:
On Fri, Dec 11, 2009 at 00:53, Dave Sherohman d...@fishtwits.com wrote:
- If oauth is the only allowed authentication method, a rogue app would
not be able to gain full access to your account. Perhaps most
importantly, it
28 matches
Mail list logo