I guess the auth code flow could be used with the command line tool
using the OpenID Connect "display" parameter with a value of
"command-line" or "text" or something when it makes its auth request. I
could go the route of defining what "command-line" display value would
mean in OIDC land. Awkward from an implementation point of view, but a
viable path.
Quite honestly, I just dont' see how any app developer would want to
require device flow. It is a bad user experience. I would even go as
far to say that the device flow is an unacceptable user experience.
Especially if cut and paste is not possible and the human has to enter
in some kind of long cryptic code by hand.
On 6/12/17 2:34 PM, Phil Hunt 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 <http://www.independentid.com>
phil.h...@oracle.com <mailto:phil.h...@oracle.com>
On Jun 12, 2017, at 11:22 AM, Justin Richer <jric...@mit.edu
<mailto:jric...@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 <bbu...@redhat.com
<mailto:bbu...@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://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://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=eodAcEm9pUWInxQkdRWT7sN0sZWWlo8oCtmgdjHY6oI&e=
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
