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

From: Gregory Prisament <[email-masked]>
Date: Tue, 10 Jan 2012 11:23:55 -0800

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

---

From: Justin Richer <[email-masked]>
Date: Tue, 10 Jan 2012 14:47:42 -0500

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:
> Using a web browser, the resource owner would login&  authenticate
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Gregory Prisament <[email-masked]>
Date: Wed, 11 Jan 2012 10:47:01 -0800

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 <[email-masked]> 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
>
>

-- 
Greg Prisament
Software Architect
PowerCloud Systems
[email-masked]
mobile: (914) 374-3587

---

From: Gregory Prisament <[email-masked]>
Date: Wed, 11 Jan 2012 10:49:00 -0800

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

---

From: Justin Richer <[email-masked]>
Date: Wed, 11 Jan 2012 15:44:54 -0500

You definitely can do that with an app-specific password using the 
resource owner password flow, but if you're already doing OAuth, why 
would you want to?

The Device flow fell by the wayside not because people didn't see value 
in it -- many do -- but nobody in the group was actively implementing 
against it and nobody wanted to pick up editorship of it. David did us 
the courtesy of at least capturing those parts of the protocol into a 
document so that they wouldn't be lost entirely, but what it really 
needs now is an editor to step up and see it through to completion. This 
WG is planning to recharter or re-form or something in the near future, 
and if there's a champion behind the Device doc (and someone willing to 
do the actual work of editing the text), then we'll see it come up again.

  -- Justin

On 01/11/2012 01:49 PM, Gregory Prisament wrote:
>> On Tue, Jan 10, 2012 at 11:47 AM, Justin Richer<[email-masked]>  wrote:

---

From: Shane B Weeden <[email-masked]>
Date: Thu, 12 Jan 2012 07:14:43 +1000

You can also use the authorization code flow with a form of custom (e.g.
manual) delivery of the authorization code from the authorization server to
your client rather than via a redirect.

Some important points about that:
The resource owner must still visit the real authorization endpoint with a
browser to authenticate and grant authorization. The authorization server
can (e.g. for manual delivery) display the azn code on the browser screen.
The resource owner in concert with the authorization server must ensure
secure timely delivery of the authorization code to the client without it
being leaked. The authorization code should have a short lifetime allowing
only sufficient time for the client to get and use it.
The client must exchange the authorization code for an access [and refresh]
token as soon as possible then securely store those for future use.

The safe and secure delivery of the authorization code to the client has
been discussed in several contexts including native mobile apps. Redirects
with custom URI schemes, backchannel delivery via notification services,
and manual delivery such as discussed above are all possible. The core spec
doesn't describe these variants in detail but there is no reason an
authorization server can't implement them.

Regards,
Shane.

From:	Justin Richer <[email-masked]>
To:	Gregory Prisament <[email-masked]>
Cc:	[email-masked]
Date:	12/01/2012 06:50 AM
Subject:	Re: [OAUTH-WG] Manual Authorization Codes -- Help/Feedback
            requested
Sent by:	[email-masked]

  -- Justin

>>> What you're describing is the Device Flow, which was pulled out of the
main
>>>> (2) "Client Credentials" with each resource owner registering a
separate
>>>> client.