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

Bill Burke <> Mon, 12 June 2017 13:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E447A127869 for <>; Mon, 12 Jun 2017 06:23:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tcW1TaRcYAJR for <>; Mon, 12 Jun 2017 06:23:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A75841273B1 for <>; Mon, 12 Jun 2017 06:23:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3969D5CB; Mon, 12 Jun 2017 13:23:23 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 3969D5CB
Authentication-Results:; dmarc=none (p=none dis=none)
Authentication-Results:; spf=pass
DKIM-Filter: OpenDKIM Filter v2.11.0 3969D5CB
Received: from ( []) by (Postfix) with ESMTP id C8AFB777CE; Mon, 12 Jun 2017 13:23:22 +0000 (UTC)
To: Aaron Parecki <>
Cc: OAuth WG <>
References: <> <>
From: Bill Burke <>
Message-ID: <>
Date: Mon, 12 Jun 2017 09:23:21 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------3668E045D4B55C5573D24C4C"
Content-Language: en-US
X-Scanned-By: MIMEDefang 2.79 on
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 ( []); Mon, 12 Jun 2017 13:23:23 +0000 (UTC)
Archived-At: <>
Subject: Re: [OAUTH-WG] oauth with command line clients
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Jun 2017 13:23:26 -0000

I've read about these techniques, but, its just not a good user 
experience.  I'm thinking more of something where the command line 
console is the sole user agent and the auth server drives a plain text 
based interaction much like an HTTP Server drives interaction with HTML 
and the browser.

This isn't anything complex.  It should be a simple protocol, but I'd 
like to piggy back on existing solutions to build some consensus around 
what I think is a common issue with using OAuth. If there isn't anything 
going on here in the OAuth group surrounding this, would be willing to 
draw up a Draft if there is interest.

On 6/11/17 11:58 PM, Aaron Parecki wrote:
> I've seen this done a few ways:
> * The 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
> <>
> @aaronpk <>
> On Sun, Jun 11, 2017 at 8:52 PM, Bill Burke < 
> <>> 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
> <>
>     <>