Re: [OAUTH-WG] Device profile usage

Justin Richer <jricher@mitre.org> Wed, 29 May 2013 13:56 UTC

Return-Path: <jricher@mitre.org>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893A321F8459 for <oauth@ietfa.amsl.com>; Wed, 29 May 2013 06:56:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.296
X-Spam-Level:
X-Spam-Status: No, score=-6.296 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mH990LxTctu for <oauth@ietfa.amsl.com>; Wed, 29 May 2013 06:56:07 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7627621F86CE for <oauth@ietf.org>; Wed, 29 May 2013 06:56:05 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E05101F0774; Wed, 29 May 2013 09:56:04 -0400 (EDT)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C79A11F079F; Wed, 29 May 2013 09:56:04 -0400 (EDT)
Received: from [10.146.15.13] (129.83.31.56) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 29 May 2013 09:56:04 -0400
Message-ID: <51A608CD.1040604@mitre.org>
Date: Wed, 29 May 2013 09:55:25 -0400
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Vincent Tsang <vincetsang@gmail.com>
References: <CANZRnTUyz6wo_5ZfghicGpNEm_=+Aw1=ChdNPdTvKkZS4YApNw@mail.gmail.com> <E625D418-5F83-41EB-BF65-09DEDF003C14@gmx.net> <CANZRnTUS4+_37EtA3bJFDvjWOC=iFzGk1PLHutzx1ijp9kMS_g@mail.gmail.com> <-8470720313341818373@unknownmsgid> <CANZRnTUpyaV6Vd88wkSG_g5tb9QeVGM60czSrpqDdEcqczoXSg@mail.gmail.com>
In-Reply-To: <CANZRnTUpyaV6Vd88wkSG_g5tb9QeVGM60czSrpqDdEcqczoXSg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------000103070503040401000200"
X-Originating-IP: [129.83.31.56]
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Device profile usage
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 May 2013 13:56:12 -0000

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 <sakimura@gmail.com 
> <mailto:sakimura@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 <vincetsang@gmail.com
>     <mailto:vincetsang@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