Yes, that is full-on OAUTH and is quite elegant from the standpoint of the security that is provided and the ease for the application. Since the authentication is being done on a user's trusted site (Twitter in this case), then the credentials are sent securely back to the application, it's very secure and trustworthy.
That demo showed the full authentication process. The application receives two pieces of authentication information during the process that it can choose to keep and re-use from then on. Twitter credentials, for example, never expire. So, in theory, once the user has logged in once, they don't have to do it again. I didn't show that part in the video, but I might have mentioned it in the dialog. On Jan 22, 6:15 pm, Flapjack <[email protected]> wrote: > I watched a YouTube video of OAUTH in action, and it seems the app > opened up a WebView which then prompted the user to login to Twitter > through their standard (or a specially tailored) HTML interface - > which then redirected back to the app once complete. > > All this redirecting / opening of WebViews seems rather clunky. Does > OAUTH offer functionality to streamline the process by allowing the > user to input their login credentials directly into the app, and have > the "work" done in the background? Or is the HTTP redirect/WebView a > necessary step in incorporating OAUTH? > > On Jan 21, 8:58 pm, Brion Emde <[email protected]> wrote: > > > > > I've been working with OAUTH and wrote a tiny client that demonstrates > > some aspects of working with Twitter's OAUTH infrastructure. > > > They require that all requests be signed, so that security information > > is encoded in the request in a public key form, that can be decoded on > > each side, to verify authenticity. It seems that once you've obtained > > a valid token and key for the user via the OAUTH mechanism, it > > shouldn't matter (and, indeed, from Twitter's point of view) does not > > matter. Once an application is registered with Twitter, you can use > > that application's credentials to obtain user credentials that allows > > the application to effect things in the user's Twitter stream and > > account. > > > On Jan 21, 4:35 pm, Flapjack <[email protected]> wrote: > > > > I would like to connect to a remote web service to retrieve data. > > > However, in doing so, I must provide this web service with credentials > > > to authenticate the client, (to disallow anonymous requests), before > > > data is returned. The only way I can think of to do this is by simply > > > passing along the credentials in the querystring with each request. > > > This method seems rather clunky, not to mention sessionless. Is there > > > a better technique? This web service is also entirely under my > > > developmental control, so I can make any necessary changes. > > > > Also, on the side of the web service, I would like to ensure that ONLY > > > requests that come directly from an android handset will be accepted > > > (have data returned). In other words, if that same request comes in > > > from a browser or iFone, data will not be returned. User-agents can be > > > easily spoofed so I don't want to rely on that. Is this at all > > > possible? The only way I can think of would be to keep the parameters > > > of each service call a secret (is this even possible?) so that a user > > > can't recreate the querystring, thus throwing an error. > > > > Looking forward to your input! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
