frederik at remote.org
Sun Jun 28 23:54:20 BST 2009
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?
> 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
> 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. 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 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?
Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
More information about the dev