[OSM-dev] OAuth down

Tom Hughes tom at compton.nu
Sun Nov 20 00:08:44 GMT 2011


On 19/11/11 23:10, Pierre GIRAUD wrote:

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

Which we don't support yet.

Actually it's a bit more complicated than that, because it might work, 
bit I haven't tested it at all so I'm not going to claim that we support it.

> 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.

You are misunderstanding what OAuth is. It is not a system for allowing 
a user to authenticate to your website (yes I know that twitter abuse it 
in that way but it is explicitly not what OAuth is intended for) rather 
it is a way for a user to grant your website permission to do things on 
our site.

> 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.

This is a basic limitation of OAuth and isn't something I can do 
anything about.

Please read the OAuth specifications if you want to know about how it 
works and what it's limitations are.

> 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.

As with Facebook, I have no knowledge of how Twitter use OAuth or 
achieve the effects that they do beyond knowing that it is well known 
that they abuse OAuth as an authentication mechanism.

I can only think of two ways to achieve the effect you use with OAuth 
though. One would be to delete old access tokens when a new one was 
created but that would be undesirable for us as, for example, a user 
with multiple JOSM installs would than authorizing one would cut the 
others off.

The other way would be to simply hide the existence of multiple access 
tokens for an application and only present a single entry in the UI for 
an application regardless of how many tokens it had. The downside of 
that would be that revoking access would have to revoke all the current 
tokens.

Tom

-- 
Tom Hughes (tom at compton.nu)
http://compton.nu/



More information about the dev mailing list