2009/3/26 Elliott Kember <[email protected]> > > Cool - yeah sorry about that. I meant to say the next time they try to > access their account. > > It'd be even better if there were another level of OAuth permissions - > "authorization only" - which just lets you log in using the account, > and only lets you call verify_credentials. > > Am I the only one that thinks this could be really cool? What are the > downsides?
That doesn't help, does it? You still need to get permission every time unless you can store your OAuth token for the next time, which is what we are trying to avoid. In my case I am providing a service for other clients to call, so I think the following would do: 1. Client app gets hold of an OAuth token as usual 2. Client app calls get_id_token on the Twitter API, Twitter returns an "id token" (essentially what you described) 3. Client app passes the id token to my web service 4. My web service calls get_id, passing in the id_token, on the Twitter API, Twitter returns the user name/id/whatever Unfortunately none of the API functions or the id token exist at the moment :P The best solution with the API that is out there today is to get the client app to pass its own token to my web service - giving my web service far more access than it needs - which kinda defeats the purpose of introducing OAuth in the first place. G.
