> If you don't have a database storing the access tokens or indefinite > sessions on your webserver storing them, then the user will have to > login everytime. There's no way to get an access token without users > going through the OAuth detour. > -Chad
That's true - but what if the OAuth detour recognizes that the app is already registers, and invisibly allows the authorization, and redirects them to the callback url? For a web-app, this is perfect - it's an invisible roundtrip, similar to OpenID's one. The user probably wouldn't even notice. In effect, I'm re-authorizing every time, and getting a new access token each time. This will only work for web-apps - but the upside is, a single button-click and you're logged in. > Won't have "read only access" accomplish this? You can check > verify_credentials and never check anything else... but the OAuth > login flow remains the same.. Sort of - but read-only access can still read DM messages, right? I'm not sure that's necessary for just logging in. On Mar 26, 9:11 pm, Graeme Foster <[email protected]> wrote: > 2009/3/26 Chad Etzel <[email protected]> > > > > > If you don't have a database storing the access tokens or indefinite > > sessions on your webserver storing them, then the user will have to > > login everytime. There's no way to get an access token without users > > going through the OAuth detour. > > -Chad > > In my case I want the client app that is getting and storing its own token > to be able to hand something to my web service so the user doesn't have to > authorize twice. > > G.
