Hi Vincent … it sounds to me like you should be looking at the code flow. It is optimized for the use case you describe (or at least as I understand it). A native application which uses an installed web browser to interact with the AS and obtain a token for your client. Using this flow, your native windows app would communicate with the AS via (for example) Firefox or IE. Your request would register a custom redirect URI, which your app would handle. When the AS sends the code back, the web browser will hand it back to your native app. Your native app would then communicate directly with the AS and exchange the code for an access token which your app could then use to communicate with its API endpoint.
-adam From: [email protected] [mailto:[email protected]] On Behalf Of Vincent Tsang Sent: Tuesday, May 28, 2013 11:32 PM To: Nat Sakimura Cc: [email protected] Subject: Re: [OAUTH-WG] Device profile usage The client is a native windows application, for instance, a document editor like MS Word. The editor can upload copies to the cloud (e.g. Amazon S3), then record the version history and notes associated with each cloud copy to our cloud service via our cloud application API (to be secured by OAuth access tokens). I think it's similar to the case with a media player application (like VLC/Windows Media Player) that sends playlist/history info to the cloud via some cloud application API. I'm just not sure which of the 4 scenarios described in the OAuth spec could fit in here... Thanks. Vincent On Wed, May 29, 2013 at 11:38 AM, Nat Sakimura <[email protected]<mailto:[email protected]>> wrote: A little more application and user context would help. A use case, so to speak. Nat 2013/05/29 12:04、Vincent Tsang <[email protected]<mailto:[email protected]>> のメッセージ: > Hi Hannes, > > Thanks for your reply. > Actually I am new to OAuth and am simply trying to search for the best > industrial practice for granting access tokens when the client to our > application API is a simple windows applications, which in most cases runs on > PC's with web browser installed. > Therefore the scenario doesn't quite match what is described in the document, > as the user doesn't need a separate machine to perform the verification; it's > just that the client application doesn't have internet browsing capability > itself (in this sense it's similar to the "device" described in this > document, though not quite) and so user needs to launch a separate browser > application. > I ended up on this device profile spec just because it seems to match closer > to our scenario when compared to the 4 cases described in the OAuth 2 spec, > but it could be the case that I didn't understand it fully. > Maybe I should rephrase my question: could someone please advice what should > be the best practice for granting OAuth tokens to clients which are native > windows applications? > > Thanks. > Vincent > > _______________________________________________ > OAuth mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
