[OSM-dev] OAuth down

[Pierre GIRAUD]

I'm probably missing something obvious. My apologizes if it's actually the case.

I don't know if we can trust that, but in the facebook example
previously given, they're talking about OAuth 2.0.

Anyway, my problem is that I cannot really cache the access token and
the corresponding secret. My application is a web application. Users
connect via a browser. My application doesn't deal with any
authentication itself. I cannot  therefore store (in a database) any
token for a user because I don't know which user is actually connected
before he logs in using the OSM OAuth service.
Well I'm already storing the username (which is the only information I
need actually) in a cookie so that they don't have to re-log in if
they close their browser.
But this cookie expires when it is 2 weeks old. I don't really want a
cookie that never expires. I can't tell why. When the cookie expires,
the user is then anonymous and is invited to log in using OSM
authorization before he can use the application.

I can of course save the information about the token in a cookie as
well, but I cannot ensure that the cookie will not be deleted. If so,
the user will be asked for permission again. Which means a new entry
in the list of authorized applications in the user's oauth settings on
the OSM site.

An other good example, is the "log on twitter" on yfrog. As far as I
know, twitter uses OAuth. If you go to yfrog.com, you can "sign in"
with twitter. Then you can sign out and sign in again. Each time, you
sign in, you're asked to authorize the application to access your
twitter data. However, if you go to your twitter account settings. In
the application tab, you can see an entry for yfrog (and only one).
Even more, it's the first one you accepted.

I hope this makes sense.

Pierre

On Sat, Nov 19, 2011 at 8:28 PM, Tom Hughes <tom at compton.nu> wrote:
> On 19/11/11 19:15, Pierre GIRAUD wrote:
>
>> My concerns now are to avoid the authorization multiplication ie. to
>> prevent users from being asked several times for a permission they
>> already gave.
>
> Well just carry on using the same access token that you got the first time.
> You only get proliferation if you keep restarting the process by getting a
> new request token, authorising it, and then converting it to an access
> token.
>
>> Shouldn't there be a mechanism that verifies that the application has
>> already been authorized?
>
> Yes - your possession of the access token and it's secret is how you prove
> that you have been authorized. If you hang on to those and reuse them then
> we will continue to allow you access.
>
>> In this application [1] described here [2], once the user has
>> authorized the application, he can log in again and again without
>> being asked for permission unless he goes to the profile and revokes
>> the authorization intentionaly.
>> [1] http://facebook-auth.appspot.com/
>> [2]
>> http://facebook-python-library.docs-library.appspot.com/facebook-python/examples/oauth.html
>
> Facebook is not directly comparable because it doesn't use OAuth as far as I
> know. It uses the proprietary Facebook Connect protocol.
>
> I don't know the details of how the Facebook protocol works, but it is
> certainly possible to do what you want with OAuth.
>
> Tom
>
> --
> Tom Hughes (tom at compton.nu)
> http://compton.nu/
>



-- 
-------------------------------------------------------------
  | Pierre GIRAUD
  | http://pierrelebricoleur.blogspot.com
  | http://www.flickr.com/photos/pierregiraud
-------------------------------------------------------------