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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
