[OAUTH-WG] Manual Authorization Codes -- Help/Feedback requested
Gregory Prisament <greg@powercloudsystems.com> Tue, 10 January 2012 19:24 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 6D5D421F8797 for <oauth@ietfa.amsl.com>; Tue, 10 Jan 2012 11:24:09 -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 Sd9dtOiOPg8v for <oauth@ietfa.amsl.com>; Tue, 10 Jan 2012 11:24:09 -0800 (PST)
Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with SMTP id 7D97321F855E for <oauth@ietf.org>; Tue, 10 Jan 2012 11:24:08 -0800 (PST)
Received: from mail-ww0-f49.google.com ([74.125.82.49]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTwyQS1a9OaHRtzmda3oRtV6MmlAk/DbQ@postini.com; Tue, 10 Jan 2012 11:24:08 PST
Received: by mail-ww0-f49.google.com with SMTP id dt13so2661711wgb.30 for <oauth@ietf.org>; Tue, 10 Jan 2012 11:23:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.19.130 with SMTP id f2mr5643721wie.12.1326223435408; Tue, 10 Jan 2012 11:23:55 -0800 (PST)
Received: by 10.227.28.87 with HTTP; Tue, 10 Jan 2012 11:23:55 -0800 (PST)
Date: Tue, 10 Jan 2012 11:23:55 -0800
Message-ID: <CAPYhiHZS_jHmxyzV5Bb3FZFYhfCArHE47SwSX-y04kFdc=rVUQ@mail.gmail.com>
From: Gregory Prisament <greg@powercloudsystems.com>
To: oauth@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: [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: Tue, 10 Jan 2012 19:30:04 -0000
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
- Re: [OAUTH-WG] Manual Authorization Codes -- Help… Gregory Prisament
- [OAUTH-WG] Manual Authorization Codes -- Help/Fee… Gregory Prisament
- Re: [OAUTH-WG] Manual Authorization Codes -- Help… Justin Richer
- Re: [OAUTH-WG] Manual Authorization Codes -- Help… Gregory Prisament
- Re: [OAUTH-WG] Manual Authorization Codes -- Help… Justin Richer
- Re: [OAUTH-WG] Manual Authorization Codes -- Help… Shane B Weeden