Re: [OAUTH-WG] oauth with command line clients
Dick Hardt <dick.hardt@gmail.com> Mon, 12 June 2017 19:00 UTC
Return-Path: <dick.hardt@gmail.com>
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 6D3CB129A97 for <oauth@ietfa.amsl.com>; Mon, 12 Jun 2017 12:00:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.71
X-Spam-Level:
X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 2wbERoqJXqsb for <oauth@ietfa.amsl.com>; Mon, 12 Jun 2017 11:59:55 -0700 (PDT)
Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E8BE129789 for <oauth@ietf.org>; Mon, 12 Jun 2017 11:59:55 -0700 (PDT)
Received: by mail-it0-x235.google.com with SMTP id m47so25122048iti.0 for <oauth@ietf.org>; Mon, 12 Jun 2017 11:59:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0lg8rWHZEOdEw5f+JpvHm9pPpCGK5Aw+iikEM27goUw=; b=LYGVYEC+Ywu42gRHLGM2dnd9y4720ASUH3+mFTZmfMXsBXfPaZnv/IVAA3YYAWMgpV iMkOzvgqemZyWo4GJ5p6UQCfdXp0crSTo2nfp+OWaZnFle2S+2OEk4vtBF5bR+EXreaa mRL6SIsj0kHwydYuStKAkWHxNoonFPMV27Xm4ufg4ipxHk8QtOGUnt4GJb/8cBPt+Bsm zQY15/AoP+iNgzhu3jAt9hU5o730t4gqC1BfMigmZgW+sBTtc990fsz4N94pK0GpVjPS 3sHW+QWWxsUXjb8Fibu3GMYDUUPPHm2Iahq2zgfFxJiHVoBm+BNa5qRKFknReh5dLp0V xGSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0lg8rWHZEOdEw5f+JpvHm9pPpCGK5Aw+iikEM27goUw=; b=kP5NyFeug1zWUvZ4NvAW+Sqrp7M897T4EpSlm3ctrXLyqenn58/pCVLV+aIib5x6Dw tMjGXc4Oq/joTV+BNSJyEA7Kc6X3KtnrgSOxKpuwDNi4dNWJhDQ7ANibsxF5xWtW0VAK aj+ZNkfH0WNNIVxVF9al6T9dMLANeyUQwxbFPhtl5t0Cjdn1x+qQ4BtC9Jh1Ib80fZD+ 851OhEp8Rg4DpANtT7eCmzm1gNa8P2WukAj2dolvch0r5BWGCyCsoylk9+JoPhwN101c GXN6WR+QQesSpcKBtLhB7k5kAA9g7YiqOXOSyJ1mKASOs/qePp3ZQoIj6UaHmUDzFhx1 eYtQ==
X-Gm-Message-State: AODbwcCDB/Jyi2cNEkqmx3oH3a4Zn7hbPPTQ7JhoL+jWLJX/9Wj6YqAF /OjGwD46lZLlxWciFYlybty9f4H0dw==
X-Received: by 10.36.82.82 with SMTP id d79mr13303351itb.90.1497293994272; Mon, 12 Jun 2017 11:59:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.30.74 with HTTP; Mon, 12 Jun 2017 11:59:33 -0700 (PDT)
In-Reply-To: <A743D557-F3BB-49EB-919D-90EFCE4A98A8@oracle.com>
References: <a496c372-b700-c6ad-06e7-c257c10d5986@redhat.com> <CAGBSGjoarSVOEdqjPJXL6BfuACnZeks4LEyBpaMSb+TQ_WFNFw@mail.gmail.com> <83057e12-1d09-1b2c-88a4-b1918c9a0b5b@mit.edu> <A743D557-F3BB-49EB-919D-90EFCE4A98A8@oracle.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Mon, 12 Jun 2017 11:59:33 -0700
Message-ID: <CAD9ie-s0VMpUJSWjzJOEY8HeyYX+zy9AHWYg3b4An6bLAUpYqQ@mail.gmail.com>
To: Phil Hunt <phil.hunt@oracle.com>
Cc: Justin Richer <jricher@mit.edu>, OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="001a11449c0aa75aa70551c7ecd8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/wI5FdosTdvPPDGuA1lLxVNfnz1Q>
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 19:00:00 -0000
+1 to the device flow if you can't pop open a system browser. If you can pop open a system browser, then a more standard flow is a better CX. On Mon, Jun 12, 2017 at 11:34 AM, Phil Hunt <phil.hunt@oracle.com> wrote: > +1 > > The point of OAuth is to break away from using UID/Password (basic auth). > > > The device flow is the best way to allow stronger authentication of the > authorizing user while still allowing a limited input device (e.g. command > line) to work. > > Phil > > Oracle Corporation, Identity Cloud Services Architect & Standards > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Jun 12, 2017, at 11:22 AM, Justin Richer <jricher@mit.edu> wrote: > > 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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Ddevice-2Dflow&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=gWeHcqrhQt-ijJ5-UXHxML5rMtR05GjKVyxqZBEeQAM&e=> > 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 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__aaronparecki.com&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=Zn85klv9a00I3Uo74zgqAelgrFUFQc72PdFwg4gkECQ&e=> > @aaronpk > <https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_aaronpk&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=g5RjhR9W1VYt00S4dV0t9ijZ4gC4HE93waQ_t7mUzUs&e=> > > > On Sun, Jun 11, 2017 at 8:52 PM, Bill Burke <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 >> https://www.ietf.org/mailman/listinfo/oauth >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=eodAcEm9pUWInxQkdRWT7sN0sZWWlo8oCtmgdjHY6oI&e=> >> > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=eodAcEm9pUWInxQkdRWT7sN0sZWWlo8oCtmgdjHY6oI&e=> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www. > ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5Y > TpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m= > j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s= > eodAcEm9pUWInxQkdRWT7sN0sZWWlo8oCtmgdjHY6oI&e= > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!
- [OAUTH-WG] oauth with command line clients Bill Burke
- Re: [OAUTH-WG] oauth with command line clients Aaron Parecki
- Re: [OAUTH-WG] oauth with command line clients Bill Burke
- Re: [OAUTH-WG] oauth with command line clients Hollenbeck, Scott
- Re: [OAUTH-WG] oauth with command line clients David Waite
- Re: [OAUTH-WG] oauth with command line clients Justin Richer
- Re: [OAUTH-WG] oauth with command line clients Phil Hunt
- Re: [OAUTH-WG] oauth with command line clients Dick Hardt
- Re: [OAUTH-WG] oauth with command line clients Bill Burke
- Re: [OAUTH-WG] oauth with command line clients Bill Burke
- Re: [OAUTH-WG] oauth with command line clients Justin Richer