The device flow is really made for cases where the client software can't
open a full browser at all, like a limited set top box or embedded
device. Since you can access a browser, you can very easily do an
authorization code flow with a native app. The only "trick" is getting
the code back to the application, and you've got several options there.
The basics go like this:
0. App gets registered with the auth server (either by hand or using
dynamic registration -- your pick, but it's a tradeoff: if the former,
you probably won't be able to use a client_secret; if the latter, you
can more easily have a client_secret but you have to manage multiple
instances of the client with separate client_id's)
1. App needs to access protected API, so it creates a request URL to the
authorization server's authorization endpoint (using response_type=code)
2. App opens the system browser (using whatever native system tools for
this) with the authorization URL created in (1)
3. User goes to the authorization page in the web browser
4. User authenticates to the authorization server (however the auth
server wants to authenticate the user)
5. User approves the application
6. Authorization server generates an auth code and appends it to the
callback URL for the application. this is where you have a few options:
6a. Callback URL uses a custom URI scheme like
"myapp://oauth?code=foobar" that opens up a callback to the running
application. This is very common on mobile systems.
6b. Callback URL goes to trusted web page that displays the code to
the user, the user copies and pastes this code into the application.
This is hardy against technology differences but requires user input.
6c. Callback URL goes to a trusted backend service that takes the
code and pushes it through some trusted means out to the application
instance. Again, this is more common on mobile platforms than on the
desktop.
6d. Callback URL goes to a temporary HTTP server stood up on
localhost that is run by the app, like
"http://localhost:93214/oauth?code=foobar";. Since the app is running
this embedded web server and it's only on localhost, it can easily grab
the code from the request.
6e. Callback URL goes to a trusted webpage that puts the code into
the HTML title element or other portion of the page, and the app scans
all open windows looking for a specific pattern. Google was fond of this
hack, for some reason, but I wouldn't recommend it.
7. Once it has the code, App calls the Token Endpoint with the code and
(if possible) its credentials, gets an access token (and optionally a
refresh token).
Personally, I've written apps that do 6a, 6b, and 6d with various levels
of complexity and success. All depends on what you have available on
your platform.
Hope this helps,
-- Justin
On 05/29/2013 12:31 AM, Vincent Tsang wrote:
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 <sakim...@gmail.com
<mailto:sakim...@gmail.com>> wrote:
A little more application and user context would help.
A use case, so to speak.
Nat
2013/05/29 12:04?Vincent Tsang <vincets...@gmail.com
<mailto:vincets...@gmail.com>> ??????:
> 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
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
