While it does add a vector for user error, the codes aren’t long and cryptic. Most implementations are 6 or 8 characters, and it’s recommended that they be case insensitive and not have ambiguous characters (I vs 1, O vs 0). And they should be all low ASCII, even just a subset of uppercase letters as suggested on the spec itself. These aren’t authorization codes or access tokens, which are meant to be machine-readable and high entropy.
— Justin > On Jun 17, 2017, at 9:24 AM, Bill Burke <bbu...@redhat.com> wrote: > > 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 <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 <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= >>> >>> <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
