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

Gregory Prisament <> Wed, 11 January 2012 18:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1330A21F8670 for <>; Wed, 11 Jan 2012 10:47:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.977
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4yXAdRs3dnor for <>; Wed, 11 Jan 2012 10:47:19 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 9363321F8627 for <>; Wed, 11 Jan 2012 10:47:17 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKTw3ZKD8pd2qB/; Wed, 11 Jan 2012 10:47:18 PST
Received: by wgbdr13 with SMTP id dr13so923601wgb.33 for <>; Wed, 11 Jan 2012 10:47:01 -0800 (PST)
MIME-Version: 1.0
Received: by with SMTP id cb10mr13042123wib.15.1326307621557; Wed, 11 Jan 2012 10:47:01 -0800 (PST)
Received: by with HTTP; Wed, 11 Jan 2012 10:47:01 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Wed, 11 Jan 2012 10:47:01 -0800
Message-ID: <>
From: Gregory Prisament <>
To: Justin Richer <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [OAUTH-WG] Manual Authorization Codes -- Help/Feedback requested
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Jan 2012 18:47:20 -0000

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.

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?


On Tue, Jan 10, 2012 at 11:47 AM, Justin Richer <> 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:
> 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.
>> (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?
>> (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

Greg Prisament
Software Architect
PowerCloud Systems
mobile: (914) 374-3587