Re: [OAUTH-WG] FW: draft-ietf-oauth-device-flow: url with code

[William Denniss <[e-mail]>]

Thanks for your review James!

On Tue, Feb 28, 2017 at 4:23 PM, Manger, James <
[e-mail]> wrote:

> Resending; not sure that OAuth email list is working at the moment.
>
>
>
> *From:* Manger, James
> *Sent:* Tuesday, 28 February 2017 9:53 AM
> *To:* [e-mail]
> *Subject:* draft-ietf-oauth-device-flow: url with code
>
>
>
> How about combining the verification_uri and user_code?
>
>
>
> The Device Flow provides a verification_uri and user_code, both of which
> have to be copied to a web browser on, say, a mobile phone. The main model
> in this draft is that the user copies the uri, then the resulting web page
> prompts for the code.
>

Correct. And note that there is a high probability that the user will make
errors, one reason why it's better for them to get the URI input first
(which may get browser auto-complete), before asking for the code.


> The draft also mentions other possibilities such as Bluetooth to do the
> “copying”. Transmitting a URI via Bluetooth, or NFC, or QR code, is quite
> common. In such cases it would be nicer to transmit the user_code as part
> of the URI.
>

I don't really see the benefit.

If you're doing some kind of out-of-band transmission (which is mentioned
as out of scope of the spec) there's no reason you can't simply transmit
both pieces of information.  We've done that before, and this is what we
do.  Having the data separate did not really alter the implementation of
this, and combining it wouldn't measurably make it simpler (but it would
make the spec more complex).

Also if the AS really wanted to, there's nothing to stop it including
whatever parameters it wanted in the verification URI today (which could
include the user code).

So I'd prefer to keep 1 protocol, designed for the browser model (which is
the only thing in-scope in the spec), that can potentially work with a wide
range of cases.


> Perhaps both modes could be supported by saying the user_code can be
> included as a query parameter on the verification_uri when it is more
> convenient for a device to transmit a single URI. Authorization Servers
> MUST accept this. The choice is to use user_code as the complete query
> string (eg https://example.com/device?wdjb-mjht) or specify a “code”
> parameter name (eg https://example.com/device?code=wdjb-mjht).
>

-1. I know for sure Google's AS will not comply with that MUST. As it is
there are some phishing concerns around this flow (documented in the spec),
and this change unfortunately makes the matter worse by allowing for
single-click phishing.

For example, we use the text today: "Enter the code displayed on your
device". And we display a picture picture of the device to help guide the
user as to the expected usage of this flow (this by itself isn't everything
– but they are important hints).


> Recommending case-insensitive punctuation-ignoring alphabetic codes is
> good, but how does a user know this is the case for a particular code?
> Perhaps the advice needs to be to use a “fancy” input field with javascript
> to convert to uppercase as the user types and handle punctuation?
>

I believe that's covered:

   The server should ignore any characters like punctuation that are not
   in the user-code character set.  Provided that the character set
   doesn't include characters of different case, the comparison should
   be case insensitive.



>
>
>
>
> [§6.1] The example user code “WDJB-MJHT” doesn’t have “24^8 bits of
> entropy”, but “log2(24 ^ 8) = 36.7 bits of entropy”.
>

Good point.

Best,
William


>
> --
>
> James Manger
>
>
>
>
>
> On Mon, Feb 27, 2017 at 9:46 AM, <[e-mail]> wrote:
>
>         Title           : OAuth 2.0 Device Flow for Browserless and Input
> Constrained Devices
>         Filename        : draft-ietf-oauth-device-flow-04.txt
>
> Abstract:
>    This OAuth 2.0 authorization flow for browserless and input
>    constrained devices, often referred to as the device flow, enables
>    OAuth clients to request user authorization from devices that have an
>    Internet connection, but don't have an easy input method (such as a
>    smart TV, media console, picture frame, or printer), or lack a
>    suitable browser for a more traditional OAuth flow.  This
>    authorization flow instructs the user to perform the authorization
>    request on a secondary device, such as a smartphone.  There is no
>    requirement for communication between the constrained device and the
>    user's secondary device.
>
> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-04
>
>
>