[OSM-dev] OAuth

Matt Amos zerebubuth at gmail.com
Mon Jun 29 11:02:34 BST 2009


On Sun, Jun 28, 2009 at 11:54 PM, Frederik Ramm<frederik at remote.org> wrote:
> Matt Amos wrote:
>>
>> at the moment there isn't an API to interrogate a token to find out
>> which capabilities it has, but if that's wanted it can be added. the
>> workflow is like this:
>>
>> 1. application developer registers with OSM, and sets up those
>> permissions which their app wants/needs,
>> 2. user uses the app, which uses its credentials to form an OAuth request,
>> 3. user is redirected to OSM where they log in and agree to none, some
>> or all of the permissions the app requested,
>> 4. OSM redirects the user back to the app's "callback" URL, although
>> the app doesn't actually need to close the loop - this can be a static
>> page saying "thanks. you can close this window and return to the app",
>
> But the callback URL receives the token, right?

it does, but it can choose to keep a copy of the request token it sent
to the server in step 2, which the server has now turned into an
"access token". so your app can either be stateless and use the
callback, or stateful and not need it.

>> 5. any call to the API using that token is forbidden if the app didn't
>> request that capability or the user didn't approve it and OK
>> otherwise.
>> 6. the user can revoke that token at any time, including while the app
>> is using it.
>
> So if my app has some sort of user accounts and per-user persistent state of
> its own (or persistent browser cookies), I can store that token and reuse it
> in later sessions.

yep.and i think this is the way the OAuth designers thought it would be used.

> But I might also choose not to have any persistent data
> in my application besides a session cookie in which I temporarily store the
> OAuth token; this would mean that the user would have to grant me permission
> again first thing in every session

yep. this is also possible.

> but it would be sort of more secure
> because I would not have those tokens hanging around, right? Would that be
> considered unusual and pile up all sorts of garbage in the OSM DB?

well... depends - it's also "less secure" because the user's password
has to go over the wire more often.

requiring a new token for each session is going to create a bit of
clutter in the oauth_tokens table, but let's see how it goes. i don't
think the clutter will be too great, but if it is then we can always
implement a system where the client can hint at an auto_revoke age or
something like that.

cheers,

matt




More information about the dev mailing list