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

David Waite <> Mon, 12 June 2017 16:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A8669129417 for <>; Mon, 12 Jun 2017 09:20:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.892
X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uT-4G2Gf82ET for <>; Mon, 12 Jun 2017 09:20:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 39C4E129408 for <>; Mon, 12 Jun 2017 09:20:38 -0700 (PDT)
Received: from [IPv6:2601:282:281:3a11:2d1b:594c:1f79:966b] (unknown [IPv6:2601:282:281:3a11:2d1b:594c:1f79:966b]) by (Postfix) with ESMTPSA id 3A262315F3; Mon, 12 Jun 2017 16:20:37 +0000 (UTC)
From: David Waite <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C206F3BB-F513-43CC-84F3-7BE19927AA21"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 12 Jun 2017 10:20:36 -0600
In-Reply-To: <>
Cc: "" <>, "" <>, "" <>
To: "Hollenbeck, Scott" <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3273)
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 16:20:48 -0000

FYI, A few years ago I did a demonstration on OpenID Connect at Cloud Identity Summit using a collection of bash scripts and command-line utilities (nc, jq). I used the macOS system command ‘open’ to launch a browser, and netcat to field the response as a poor man’s HTTP endpoint.  The code for that presentation is at

A few options for the user challenge/consent portion of the authentication are:
- pop up the system browser (you can use window.close() to dismiss on redirect back to your client) - thats the one I used.
- device flow
- use a console browser like lynx or ELinks (which has rudimentary ecmascript support at a fairly big cost)
- use non-HTML request/response API (around some custom MIME type) to drive a user agent through the authentication/scope approval/etc stages of your AS
- punt and use resource owner credentials grant.

> On Jun 12, 2017, at 7:29 AM, Hollenbeck, Scott <> wrote:
> From: OAuth [ <>] On Behalf Of Bill Burke
> Sent: Monday, June 12, 2017 9:23 AM
> To: Aaron Parecki < <>>
> Cc: OAuth WG < <>>
> Subject: [EXTERNAL] Re: [OAUTH-WG] oauth with command line clients
> 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.
> [SAH] I’m certainly interested! I have a use case for federated client authentication and authorization for the Registration Data Access Protocol (RDAP) that has the same need for command line web service clients like wget and curl.
> Scott
> _______________________________________________
> OAuth mailing list
> <>
> <>