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 <g...@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 <jric...@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 > g...@powercloudsystems.com > mobile: (914) 374-3587 -- Greg Prisament Software Architect PowerCloud Systems g...@powercloudsystems.com mobile: (914) 374-3587 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
