There is no detailed information about xauth right now, but the WRAP
specification did allow to fetch access token using username/password,
that makes a proxy script possible.I think this is xauth about: get
access token using username/password and then do the rest things using
oauth.

I'm still waiting for the approval of my request to try xauth, maybe I
can figure out how to do this when I can try xauth myself :-)

On Feb 12, 5:40 pm, Jesse Stay <jesses...@gmail.com> wrote:
> On Fri, Feb 12, 2010 at 2:40 AM, Brian Smith <br...@briansmith.org> wrote:
> > yegle wrote:
>
> >> Basically, a API proxy script works as a middleman between twitter and
> >> twitter client, little like man-in-the-middle attack.It's possible to
> >> do this if the authentication is made in HTTP basic auth.But there is
> >> no way to do the same thing with OAuth. The base string of an OAuth
> >> request contains the domain of the HTTP request, so all client
> >> developers modify their code if they want to suite the need of API
> >> proxy.
>
> >> This is really a disaster for all Chinese twitter users.
>
> > Read Raffi's post from a few hours ago entitled "What's up with OAuth?"
> > where he describes xAuth. Also, look at the OAuth WRAP draft specification,
> > which defines something very similar to xAuth. In the (near) future,
> > Twitter-approved applications will be able to get OAuth authorized with just
> > the user's username and password, without forcing the user to visit the
> > Twitter website. After they are authorized, they can proxy their requests
> > like before. The proxies will undoubtedly need to be modified, but the
> > modifications will not be too bad.
>
> Brian, I thought that was the case originally, but after reading his latest
> draft, I'm thinking the opposite may be the case.  I think xAuth requires
> all users to go through the Twitter website, but applications wanting to
> transfer authority to another application or website (via an API) will be
> able to make calls on behalf of those applications. In order for
> application-to-application transfer to occur though, I think users still
> have to go through the Twitter website to log in.  Then an application can
> take that user's token, pass it onto the other application, and the other
> application can get permission from Twitter to make calls on behalf of that
> user.  No usernames or passwords are passed in this method, if I understand
> it correctly.  Raffi, please correct me if I'm wrong.
>
> If that's not the case, there is still a major concern for phishing.  I'm
> not sure what the answer is here - it's China or phishing, tough decision.
>
> Jesse

Reply via email to