Subject: [OAUTH-WG] Device profile usage

From: Vincent Tsang <[email-masked]>
Date: Tue, 28 May 2013 00:47:26 +0800

Hi all,

I'm looking for the most suitable solution to grant the access token for
accessing our cloud service API for clients which is a windows application
with no internet browsing capability itself (though it can be installed on
a PC with access to internet). After some research, it seems the device
profile (http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00)  is
the flow addressing the closest use case to ours (but still not exact).

Could someone please advise whether it is a good idea for us to follow this
draft (is it still active?) for the OAuth flow for our use case, or else
does someone know which should be the best flow that we should follow
instead?

Thanks in advance!

Vincent

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 27 May 2013 20:37:19 +0300

Hi Vincent,

from a pure standardization point of view that draft is long expired. 

This document was initially created because the device profile was one of the least mature parts of the OAuth 2.0 protocol. We were hoping to gain a bit more deployment experience before continuing the work but it seems that we dropped the ball a bit. More important work items came along. I had tried to resurrect it but that again was probably a year ago. 

The challenge was to find out what various industry players are doing so that we can standardize the best current practice. 

Would you be interested to work on this document again? 

Ciao
Hannes

PS: Does your environment have a similar problem as described in the abstract of the mentioned document, namely: 

"
 ... 
    devices which do not have an easy data-entry method (e.g. game
   consoles or media hubs), but where the end-user has separate access
   to a user-agent on another computer or device (e.g. home computer, a
   laptop, or a smart phone).
"

On May 27, 2013, at 7:47 PM, Vincent Tsang wrote:

> Hi all,
> 
> I'm looking for the most suitable solution to grant the access token for accessing our cloud service API for clients which is a windows application with no internet browsing capability itself (though it can be installed on a PC with access to internet). After some research, it seems the device profile (http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00)  is the flow addressing the closest use case to ours (but still not exact). 
> 
> Could someone please advise whether it is a good idea for us to follow this draft (is it still active?) for the OAuth flow for our use case, or else does someone know which should be the best flow that we should follow instead?
> 
> Thanks in advance!
> 
> Vincent
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Vincent Tsang <[email-masked]>
Date: Wed, 29 May 2013 11:03:54 +0800

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

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 29 May 2013 12:38:28 +0900

A little more application and user context would help.
A use case, so to speak.

Nat

2013/05/29 12:04、Vincent Tsang <[email-masked]> のメッセージ:

> 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
>

---

From: Vincent Tsang <[email-masked]>
Date: Wed, 29 May 2013 12:31:30 +0800

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

---

From: Todd W Lainhart <[email-masked]>
Date: Wed, 29 May 2013 09:26:42 -0400

On behalf of what will the access token be granted - the app (e.g. Word), 
or the user running the app?

Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
[email-masked]

From:   Vincent Tsang <[email-masked]>
To:     Nat Sakimura <[email-masked]>, 
Cc:     "[email-masked]" <[email-masked]>
Date:   05/29/2013 12:31 AM
Subject:        Re: [OAUTH-WG] Device profile usage
Sent by:        [email-masked]

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

Nat

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.

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Wed, 29 May 2013 13:54:10 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Vincent Tsang
Sent: Tuesday, May 28, 2013 11:32 PM
To: Nat Sakimura
Cc: [email-masked]
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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> のメッセージ:

> [email-masked]<mailto:[email-masked]>

---

From: Justin Richer <[email-masked]>
Date: Wed, 29 May 2013 09:55:25 -0400

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 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).
> VLC/Windows Media Player) that sends playlist/history info to the 
> cloud via some cloud application API.
>     2013/05/29 12:04?Vincent Tsang <[email-masked]
>     <mailto:[email-masked]>> ??????:
>
>     > 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
>     >
>     > [email-masked] <mailto:[email-masked]>

---

From: Vincent Tsang <[email-masked]>
Date: Wed, 29 May 2013 22:20:30 +0800

The same user could run the app on multiple computers and I want to
distinguish each running instance, so I think it's the app?

Thanks.
Vincent

On Wednesday, May 29, 2013, Todd W Lainhart wrote:

>  *
> 550 King Street, Littleton, MA 01460-1250**
> 1-978-899-4705
> 2-276-4705 (T/L)
> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>*
>
>
>
>
> From:        Vincent Tsang <[email-masked] <javascript:_e({},
> 'cvml', [email-masked]');>>
> To:        Nat Sakimura <[email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>>,
> Cc:        "[email-masked] <javascript:_e({}, 'cvml', [email-masked]');>"
> <[email-masked] <javascript:_e({}, 'cvml', [email-masked]');>>
> Sent by:        [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>
> ------------------------------
>
>
>
> On Wed, May 29, 2013 at 11:38 AM, Nat Sakimura <[email-masked]*<javascript:_e({}, 'cvml', [email-masked]');>>
> wrote:
> 2013/05/29 12:04、Vincent Tsang <[email-masked]* <javascript:_e({},
> 'cvml', [email-masked]');>> のメッセージ:
>
> > Hi Hannes,
> >
> > Thanks for your reply.
> > [email-masked]* <javascript:_e({}, 'cvml', [email-masked]');>
> > *https://www.ietf.org/mailman/listinfo/oauth*<https://www.ietf.org/mailman/listinfo/oauth>
> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>

---

From: Justin Richer <[email-masked]>
Date: Wed, 29 May 2013 10:21:42 -0400

Yes, it's the app that is granted a token on behalf of the user. This is 
a very classic OAuth pattern.

  -- Justin

On 05/29/2013 10:20 AM, Vincent Tsang wrote:
>     On behalf of what will the access token be granted - the app (e.g.
>     Word), or the user running the app?
>
>     *
>
>
>     Todd Lainhart
>     Rational software
>     IBM Corporation
>     Cc: "[email-masked] <javascript:_e({}, 'cvml',
>     [email-masked]');>" <[email-masked] <javascript:_e({}, 'cvml',
>     [email-masked]');>>
>     ------------------------------------------------------------------------
>
>
>
>     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.
>     On Wed, May 29, 2013 at 11:38 AM, Nat Sakimura
>     <[email-masked] <javascript:_e({}, 'cvml',
>     [email-masked]');>> wrote:
>     2013/05/29 12:04?Vincent Tsang <[email-masked]
>     <javascript:_e({}, 'cvml', [email-masked]');>> ??????:
>
>     > Hi Hannes,
>     >
>     > Thanks for your reply.
>     > [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>
>     > _https://www.ietf.org/mailman/listinfo/oauth_

---

From: Todd W Lainhart <[email-masked]>
Date: Wed, 29 May 2013 13:27:44 -0400

I asked, because I wondered if the client credentials flow or the auth 
code flow was the more appropriate flow. It sounds like you want to 
identify both the client and the user, but it's unclear if it's required 
that the client authenticate.  Also, I can't tell from your use case if 
OAuth is the appropriate solution.

If it is the right solution, Justin's response sounds like the way to go.

Todd Lainhart
Rational software
IBM Corporation

From:   Vincent Tsang <[email-masked]>
To:     Todd W Lainhart/Lexington/IBM@IBMUS, 
Cc:     "[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, Nat Sakimura <[email-masked]>
Date:   05/29/2013 10:29 AM
Subject:        Re: Device profile usage

Thanks. 
Vincent

Todd Lainhart
Rational software
IBM Corporation

Thanks. 
Vincent 

Nat