Re: [OAUTH-WG] Manual Authorization Codes -- Help/Feedback requested

Gregory Prisament <greg@powercloudsystems.com> Wed, 11 January 2012 18:49 UTC

Return-Path: <greg@enablenetworks.com>
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 9EF8721F86A8 for <oauth@ietfa.amsl.com>; Wed, 11 Jan 2012 10:49:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.977
X-Spam-Level:
X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
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 mk5cyTkMs0il for <oauth@ietfa.amsl.com>; Wed, 11 Jan 2012 10:49:03 -0800 (PST)
Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with SMTP id 860BE21F868A for <oauth@ietf.org>; Wed, 11 Jan 2012 10:49:02 -0800 (PST)
Received: from mail-we0-f176.google.com ([74.125.82.176]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKTw3ZnlR+pubrbqvtWGSsGGQAIBv4cKRS@postini.com; Wed, 11 Jan 2012 10:49:02 PST
Received: by werm10 with SMTP id m10so1123356wer.35 for <oauth@ietf.org>; Wed, 11 Jan 2012 10:49:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.138.219 with SMTP id a69mr3379948wej.6.1326307740659; Wed, 11 Jan 2012 10:49:00 -0800 (PST)
Received: by 10.227.28.87 with HTTP; Wed, 11 Jan 2012 10:49:00 -0800 (PST)
In-Reply-To: <CAPYhiHapSBJiZkbYFyv7eJ-FoPmxi84uU2_w6gqjptH2jCaKyw@mail.gmail.com>
References: <CAPYhiHZS_jHmxyzV5Bb3FZFYhfCArHE47SwSX-y04kFdc=rVUQ@mail.gmail.com> <4F0C95DE.1000401@mitre.org> <CAPYhiHapSBJiZkbYFyv7eJ-FoPmxi84uU2_w6gqjptH2jCaKyw@mail.gmail.com>
Date: Wed, 11 Jan 2012 10:49:00 -0800
Message-ID: <CAPYhiHY-x8fbUyxz9iZutm1rU3W6L3K+Do-QP+=k2z2xdka6+Q@mail.gmail.com>
From: Gregory Prisament <greg@powercloudsystems.com>
To: Justin Richer <jricher@mitre.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Manual Authorization Codes -- Help/Feedback requested
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, 11 Jan 2012 18:49:03 -0000

Correction: Last paragraph should read:
... Do you think an authorization server could implement
application-specific passwords, passing it off as the "resource owner
credentials" grant type...

On Wed, Jan 11, 2012 at 10:47 AM, Gregory Prisament
<greg@powercloudsystems.com> wrote:
> Thanks for the link, that's very similar to what I'm going for.
>
> Any idea why people lost interest in the Device Flow?  It seems like a
> useful option to have!
>
> Also, in doing some research, I came across Google's
> "application-specific passwords", which seem to be another way to
> solve this problem.
> http://support.google.com/mail/bin/answer.py?hl=en&answer=1173270
>
> Any thoughts on application-specific passwords.  Do you think an
> authorization server could implement application-specific passwords,
> passing it off as the "client credentials" grant type.  Would that be
> in spec?
>
> Cheers,
> Greg
>
> On Tue, Jan 10, 2012 at 11:47 AM, Justin Richer <jricher@mitre.org> wrote:
>> What you're describing is the Device Flow, which was pulled out of the main
>> document a while ago and now sits here, somewhat outdated and unloved:
>>
>> http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00
>>
>> In this, the app gives the user a short code that they enter into a URL, do
>> the authorization there, and get a short code back. It's effectively the
>> same as the auth code flow, but it does the dance without HTTP redirects.
>>
>>  -- Justin
>>
>>
>> On 01/10/2012 02:23 PM, Gregory Prisament wrote:
>>>
>>> Hello,
>>> I am developing a REST API and trying to follow the OAuth 2.0 protocol
>>> for authentication, and have a few questions for you good folks.
>>>
>>> The use case I'm interested in is native applications (such as linux
>>> command-line programs) that are unable or unwilling to involve a
>>> user-agent.  In this case, it seems redirection-based flows
>>> ("Authorization Code" and "Implicit Grant Types") are out!  That
>>> leaves "Client Credentials" and "Resource Owner Credentials".
>>>
>>> "Client Credentials" do not seem appropriate because the client may be
>>> installed on multiple machines and used by different resource owners.
>>>
>>> "Resource Owner Credentials" COULD work, but I'd rather not require
>>> the resource owner to reveal their username and password.
>>>
>>> One solution, which seems reasonable to me, would be to extend OAuth2
>>> to include another grant type called "Manual Authorization Code".
>>> Using a web browser, the resource owner would login&  authenticate
>>>
>>> with the authorization server (using session log-on, etc).  From there
>>> they could enter an Application ID and press a button "Generate Manual
>>> Authorization Code".  The resource owner would then type this Manual
>>> Authorization Code into the client, and the client could exchange it
>>> for an Access Token.
>>>
>>> But before I go down this route -- writing an extension, etc.. -- I
>>> wanted the WG's feedback.  It seems there are a few different ways to
>>> handle this use case and was curious which you think best matches the
>>> intentions of the OAuth2 spec.
>>>
>>> POSSIBLE APPROACHES:
>>> (1) "Manual Authorization Code" extension.
>>> See description above.
>>>
>>> (2) "Client Credentials" with each resource owner registering a separate
>>> client.
>>> We could achieve a similar effect to (1) by using "Client
>>> Credentials".  Say the client is a command-line program
>>> "example-client-cli", which a large number of resource owners have
>>> downloaded and installed.  Each resource owner would register the
>>> client with the authorization server and configure their local install
>>> by telling it the client_id and client_secret.
>>>
>>> (3) Something else entirely?
>>>
>>> QUESTIONS FOR YOUR:
>>> (Q1) Has the WG thought about this particular use case ("CLI clients")
>>> and do you have a recommended authorization approach.
>>> (Q2) Do Manual Authorization Codes make sense?  Would anyone else find
>>> it useful to have - if I were to write up an extension document for
>>> it?
>>>
>>>
>>> Thanks in advanced for you help!
>>> Cheers,
>>> Greg Prisament
>>> Software Architect
>>> PowerCloud Systems
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>
>
> --
> Greg Prisament
> Software Architect
> PowerCloud Systems
> greg@powercloudsystems.com
> mobile: (914) 374-3587



-- 
Greg Prisament
Software Architect
PowerCloud Systems
greg@powercloudsystems.com
mobile: (914) 374-3587