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

["Manger, James" <[e-mail]>]

>>> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-04

>> 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 the device is always used with a pre-installed companion mobile app: no benefit.
If the device has ample screen size for "To register, visit <uri> and enter <code>": no benefit.
If the device can use NFC/BLE/QR-code/… to transmit a URI: benefit; can get verification_uri and user_code to a mobile browser without anything else (on the device or on the mobile).

Scenario: a device with no screen, just a few LEDs; the instructions say "to activate, tap the device with your mobile (after enabling NFC or bluetooth)".
User taps with mobile; browser launches; AS shows picture of device and asks user to confirm LEDs are flashing red/green/red/green… (on form with CSRF-protection); user click Yes; next device polling token request succeeds.

This scenario is harder without a standard way to combine verification_uri and user_code into a single URI.


> 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.

My guess is that "transmitting both pieces of info" requires special-purpose code that understands those 2 pieces. Whereas browsing to a transmitted URI is generic.

>  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.

It is still the browser model; it's just how the URI and code get to the browser.

 >> 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.

I didn't mean to imply the AS had to *finish* the flow immediately when uri?code was accessed. An AS can still display anti-phishing measures requiring explicit user clicks to continue. The AS could still display a picture of the device.

I do concede that requiring a code to be manually entered is a specific phishing defence so any alternative should probably be specified separately.

> 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 …

I guess I read that as a suggestion for server-side code. But the user needs a hint at the client-side as they enter the code.
This is a minor detail. A web form could, for instance, say "case and punctuation are ignored" below the code input field.
  
--
James Manger