Naveen, I have to disagree with your recommendation that we not finish this
work. People have been using variants of the device flow for years.
Standardizing it will improve interoperability. Also, standardizing it will
make the security considerations for using it commonly available to
implementers – whereas currently people are mostly operating in the dark or
based on their own intuitions of what’s safe and what’s not.
If you believe that there are specific things we should add to the security
considerations, please say what they are, and we can do so. But saying “stop
and wait for something else that isn’t defined yet” isn’t a helpful or
realistic position to take.
-- Mike
From: [email protected] <[email protected]> On Behalf Of Naveen Agarwal
Sent: Thursday, May 31, 2018 12:39 AM
To: William Denniss <[email protected]>
Cc: Brian Campbell <[email protected]>; [email protected];
[email protected]; oauth <[email protected]>;
[email protected]
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-device-flow-09.txt> (OAuth
2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed
Standard
I have a general concern on making the device flow a standard as this suffers
from a number of issues that are quite fatal. At Google we have limited this
flow to be used for very basic/limited scopes as phishing concerns are very
real. Also the protocol suffers from clients polling (overloading the servers)
and server having to keep a large amount of state. I think this protocol is
close to its useful end of life (at Google) and we are working on alternatives
with stronger client attestation that also mitigate other issues. Separately,
we have seen a lot more abusers/hackers use OAuth in various forms to attack
users.
I don't know how many IDPs have implemented this flow but by making it a
standard, a lot more people will implement it and I'm sure they will not be
able to avoid the issues that are highlighted.
Sorry, I know it has taken a lot of work to get the document to his stage so my
comments may feel too harsh and I apologize. Please do know that I have been
quite involved in this protocol from the beginning and we have gone through a
lot of pain and have been discussing shutting this down fairly regularly. So
this is to start the conversation if we think this protocol is for the future
or just something from our past that we want to see it documented as a standard.
Thanks
Naveen
On Wed, May 30, 2018 at 5:06 PM, William Denniss
<[email protected]<mailto:[email protected]>>
wrote:
On Wed, May 30, 2018 at 3:48 PM, Brian Campbell
<[email protected]<mailto:[email protected]>> wrote:
I realize this is somewhat pedantic but I don't think referencing 4.1.2.1
works given how RFC 6749 set things up. Rather I believe that the device
flow needs to define and register "access_denied" as a valid token endpoint
response error code (it's not a token endpoint response error per RFC 6749
sec 5.2 nor has it been registered https://www.iana.org/assignmen
ts/oauth-parameters/oauth-parameters.xhtml#extensions-error). Also
invalid_grant is a a token endpoint response error from RFC 6749 sec 5.2 so
that reference is needed and appropriate. RFC 6749 Sec 4.1.2.1
<https://tools.ietf.org/html/rfc6749#section-4.1.2> defines errors returned
from the authorization endpoint. But the device flow errors are from the
token endpoint.
Yes, that's true. It's still the token endpoint, so 5.2 does in fact apply,
it's just we're mixing in authorization-style actions which were not previously
considered/used for that endpoint.
Do you have any proposed text to resolve this?
On Wed, May 30, 2018 at 4:27 PM, William Denniss <
[email protected]<mailto:[email protected]>> wrote:
> Hi Andrew,
>
> On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras <
> [email protected]<mailto:[email protected]>>
> wrote:
>
>> Hi William
>>
>> You are right that the document explicitly indicates which error codes
>> may be returned. However I think it's ambiguous as to which error within
>> Section 5.2 of RFC6749 would apply in the scenario of a user not granting
>> access.
>>
>> I think that this ambiguity is highlighted further by the Google
>> implementation (https://developers.google.com
>> /identity/protocols/OAuth2ForDevices#step-6-handle-
>> responses-to-polling-requests
>> <https://developers..google.com/identity/protocols/OAuth2ForDevices#step-6-handle-responses-to-polling-requests<http://google.com/identity/protocols/OAuth2ForDevices#step-6-handle-responses-to-polling-requests>>)
>> not adhering to the explicit statement of the document and electing to use
>> a (more appropriate) error code that exists outside of section 5.2..
>>
>>
>
> Oh, I see what you mean now. Yes, given this is an authorization request,
> not a token request, the errors from Section 4.1.2.1
> <https://tools.ietf.org/html/rfc6749#section-4.1.2> are more relevant.
>
> I believe it was the authors intention to reference that set of errors, so
> I will plan to update the doc to reference 4..1.2.1 instead. Good catch!
> Thank you.
>
>
>>
>> On Thu, May 31, 2018 at 8:06 AM, William Denniss
>> <[email protected]<mailto:[email protected]>>
>> wrote:
>>
>>> Hi Andrew,
>>>
>>> On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras
>>> <[email protected]<mailto:[email protected]>>
>>> wrote:
>>>
>>> Hello
>>>>
>>>>
>>>> Do we feel that the document should be more specific in addressing how
>>>> the authorization service should respond to a device access token request
>>>> when the user has refused to grant access to the device?
>>>>
>>>>
>>>> The document currently indicates in section 3.5 that a success response
>>>> defined in section 5.1 of RFC6749, an error as defined in section 5.2 of
>>>> RFC6749 (this includes invalid_request, invalid_client, invalid_grant,
>>>> unauthorized_client, unsupported_grant_type, and invalid_scope), or a new
>>>> device flow error code (authorization_pending, slow_down, and
>>>> expired_token) may be returned in a response to a device token request
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
