Re: [OAUTH-WG] oauth with command line clients

Justin Richer <jricher@mit.edu> Mon, 12 June 2017 18:22 UTC

Return-Path: <jricher@mit.edu>
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 46CB112EB63 for <oauth@ietfa.amsl.com>; Mon, 12 Jun 2017 11:22:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUjcPOsia92I for <oauth@ietfa.amsl.com>; Mon, 12 Jun 2017 11:22:30 -0700 (PDT)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA4B12EB66 for <oauth@ietf.org>; Mon, 12 Jun 2017 11:22:28 -0700 (PDT)
X-AuditID: 12074425-78fff700000009de-6a-593edbe3a476
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id FC.13.02526.3EBDE395; Mon, 12 Jun 2017 14:22:27 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v5CIMQuG008256; Mon, 12 Jun 2017 14:22:26 -0400
Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v5CIMNi1012190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 12 Jun 2017 14:22:24 -0400
To: Aaron Parecki <aaron@parecki.com>, Bill Burke <bburke@redhat.com>
Cc: OAuth WG <oauth@ietf.org>
References: <a496c372-b700-c6ad-06e7-c257c10d5986@redhat.com> <CAGBSGjoarSVOEdqjPJXL6BfuACnZeks4LEyBpaMSb+TQ_WFNFw@mail.gmail.com>
From: Justin Richer <jricher@mit.edu>
Message-ID: <83057e12-1d09-1b2c-88a4-b1918c9a0b5b@mit.edu>
Date: Mon, 12 Jun 2017 14:22:20 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CAGBSGjoarSVOEdqjPJXL6BfuACnZeks4LEyBpaMSb+TQ_WFNFw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------F0A4CE172F5B267BAA005BBD"
Content-Language: en-US
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsUixCmqrPv4tl2kwcNnChbnVrlZ9G7dyWhx 8u0rNgdmjyVLfjJ5NMxM83i/7ypbAHMUl01Kak5mWWqRvl0CV8bfk6uZC1Z4VXRtfMjawHjG vIuRk0NCwERixvW5TF2MXBxCAouZJN7+3MYO4WxklLgyv58VwrnNJNG7/iY7SIuwgLlEx65f QAkODhEBV4lrnZ4gYWYBWYnWk5egmlsYJRbv+MEKkmATUJWYvqaFCcTmFbCS2Hp9PwuIzQIU 37f+CCOILSoQI/Fow1moGkGJkzOfsIDM5xQIlHh70BZifpjEpXffGCFscYlbT+YzTWAUmIWk YxaSsllIyiBsM4l5mx8yQ9jyEtvfzgGyOYBsNYllrUow4eats5kXMLKvYpRNya3SzU3MzClO TdYtTk7My0st0rXQy80s0UtNKd3ECIoLdhfVHYxz/nodYhTgYFTi4WWYahcpxJpYVlyZe4hR koNJSZR3yxWbSCG+pPyUyozE4oz4otKc1OJDjBIczEoivOzAaBTiTUmsrEotyodJSXOwKInz ims0RggJpCeWpGanphakFsFkZTg4lCR4T9wCahQsSk1PrUjLzClBSDNxcIIM5wEaLnUdZHhx QWJucWY6RP4Uo6KUOO97kGYBkERGaR5cLyhtJbw9bPqKURzoFWFeDZAqHmDKg+t+BTSYCWjw dZCPeItLEhFSUg2M5pVmBzZf1N3TF13xq2W/1wKLp5yPTi3i63+byqO2Osx+v05rzfkF8pOr 67KPFE1Md7vet2TlhAmvOU/N2z/p+UyeZ2fd97yQOWFkn+ggeEik59CO96JXd2hpTTa23Ln+ q+HeDVXfjdYempJ47ecphgnR4iWnOn1v/+ZJmLwgVs9683bff3/cbimxFGckGmoxFxUnAgBZ SW+sNgMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/SZTHH9TvqfCxgsP1H1OlNA8MD3s>
Subject: Re: [OAUTH-WG] oauth with command line clients
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 12 Jun 2017 18:22:33 -0000

I second the recommendation to use the device flow for this kind of 
system. The commandline client would print out a text string for the 
user to enter into their browser elsewhere.

If you can pop up a system browser then it's even easier and you can 
just use the auth code flow, but it's a lot to assume that a commandline 
app can have that kind of capability available to it. Printing out a 
string? That's easy and universal. That's why I say go with the device flow.

The thing is, at the end of the day, you need the user to authenticate 
to the AS if you're going to get delegated access from them. That's 
really the whole point of the OAuth protocol, after all. So you can 
either do that in a local browser of some kind (like popping a system 
browser), on another device (with the device flow), or you can be evil 
and use the username/password grant and just steal the user's 
credentials yourself. If it's not clear, I don't recommend that, 
basically ever.

  -- Justin


On 6/11/2017 11:58 PM, Aaron Parecki wrote:
> I've seen this done a few ways:
>
> * The Device Flow: 
> https://tools.ietf.org/html/draft-ietf-oauth-device-flow which is what 
> you see on browserless devices like the Apple TV logging in to a cable 
> provider from your phone. A short code is generated and displayed on 
> the screen, you launch a browser on your phone and enter the code. 
> This would work just as well from the command line on the same device.
> * I've also seen apps use the authorization flow, by displaying the 
> authorization URL on the command line prompt and instructing the user 
> to open it in a browser. The redirect URI is a hosted web page that 
> displays the authorization code and instructs the user to paste it 
> back at the terminal.
> * The command line app can launch an HTTP server on localhost and use 
> that as the redirect URL for the authorization code flow. This option 
> ends up being the most seamless since it works like a traditional flow 
> without any special instructions to the user.
>
> ----
> Aaron Parecki
> aaronparecki.com <http://aaronparecki.com>
> @aaronpk <http://twitter.com/aaronpk>
>
>
> On Sun, Jun 11, 2017 at 8:52 PM, Bill Burke <bburke@redhat.com 
> <mailto:bburke@redhat.com>> wrote:
>
>     Has anybody done any spec work around doing oauth from command
>     line interfaces?  We're looking for something where the auth
>     server can generate text-based challenges that are rendered in the
>     console window that query for simple text input over possibly
>     multiple requests.  I'm not talking about Resource Owner or Client
>     Credentials grant.  The command line client may not know the
>     credential types required for a successful token request. It would
>     be easy to write a simple protocol, but I'd rather just do
>     something around any existing internet draft or rfc that somebody
>     has put some thought into.  Hope I'm making sense here.
>
>     Thanks,
>
>     Bill Burke
>
>     Red Hat
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/oauth
>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth