OAuth is great, in certain circumstances. In others, it's not so great. Circumstances for which it is great include: - consumer web sites; and - consumer client applications that have access to a reasonable browser on the client device in both cases with the qualification that the authorization pages of the service provider are in a language (e.g., English, Japanese, etc.) that is the same as that used by the consumer.
In these circumstances, OAuth as defined by the specifications and implemented by twitter works very well. Circumstances for which it is not so great include: - consumer client applications that do not have access to a reasonable browser on the client device; and - consumer client applications and web sites that are in languages for which service authorization pages in those languages are not available. In these circumstances, OAuth as defined by the specifications and implemented by twitter does not work so well. Currently, in circumstances where OAuth does not work very well, twitter client applications and web-sites can resort to Basic Authentication. The drawbacks to this are obvious: - the user must give their twitter password to the client; - at some point twitter will no longer support Basic Authentication; and - the source of tweets created by these clients is "API" rather than the client's name. Pooh pooh the last drawback if you will, but to some it is important. Now, the fact of the matter is that some users are perfectly comfortable in giving their twitter passwords to client applications and web-sites, even where those clients support OAuth. I don't think these users should be penalized and forced to use OAuth if'n and when'n twitter drops support for Basic Authentication. And if'n and when'n twitter drops support for Basic Authentication, client applications and web-sites that now only support Basic Authentication will be forced to support OAuth. Myself, I don't think that's an unreasonable requirement, but others may differ. And I don't think these creators should have to forgo having their client's name as the source of tweets their clients create, now or ever, just because their users chose to trust them to use Basic Authentication. So I propose the following enhancement to twitter's OAuth implementation: Allow a userID and password to be included as optional parameters of an oauth/access_token request. If supplied and authentic, they would cause a valid access token to be returned without the user having visited the authorize URL and approved the access. Alternately, the userID and password could be optional on an oauth/request_token request, in which case, if supplied and authentic, the request would return a valid access token, rather than a request token, again without the user having visited the authorize URL and approved the access. The advantage to this alternative is it reduces by one the number of API calls needed. I believe either of these alternatives is a viable solution for the circumstances where the existing OAuth implementation does not work so great. Comments expected and welcome. Jim Renkel -----Original Message----- From: email@example.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of twittme_mobi Sent: Friday, September 04, 2009 08:39 To: Twitter Development Talk Subject: [twitter-dev] Re: Mobile oAuth I am also interested in mobile oath solution. twitter guys should think of something before deprecating basic auth On Aug 20, 8:01 am, Cameron Kaiser <spec...@floodgap.com> wrote: > > I have a mobile based twitter client in the field and have implemented > > oAuth for this client. Some of the devices are either very low memory > > or have primitive browsers that dont support the rendering of the > > 'allow' / 'deny' access page (http://twitter.com/oauth/authorize). I > > have tried the obvioushttp://m.twitter.com/oauth/authorizebut this > > seems to serve the same standard webage. > > > So Im looking for nat previous info or plans of a lightweight > > implementation of oAuth access page for twitter. > > I'm also particularly interested in such a page, especially one a text > browser could access such as Lynx or w3m. > > -- > ------------------------------------ personal:http://www.cameronkaiser.com/-- > Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com > -- Adore, v.: To venerate expectantly. -- Ambrose Bierce ----------------------