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

Justin Richer <> Tue, 10 January 2012 19:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A9EF11E8071 for <>; Tue, 10 Jan 2012 11:48:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nmMMg1zJlMHl for <>; Tue, 10 Jan 2012 11:48:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 74F7221F8806 for <>; Tue, 10 Jan 2012 11:48:33 -0800 (PST)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id C0DFF21B0AF1; Tue, 10 Jan 2012 14:48:29 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG ( []) by (Postfix) with ESMTP id AA2FB21B0AEF; Tue, 10 Jan 2012 14:48:29 -0500 (EST)
Received: from [] ( by IMCCAS01.MITRE.ORG ( with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 10 Jan 2012 14:48:29 -0500
Message-ID: <>
Date: Tue, 10 Jan 2012 14:47:42 -0500
From: Justin Richer <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
To: Gregory Prisament <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
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: Tue, 10 Jan 2012 19:48:34 -0000

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 

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