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 < wdenniss=40google....@dmarc.ietf.org> wrote: > > On Wed, May 30, 2018 at 3:48 PM, Brian Campbell < > bcampb...@pingidentity.com> 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 >> <https://www.iana.org/assignments/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 < >> wdenniss=40google....@dmarc.ietf.org> wrote: >> >> > Hi Andrew, >> > >> > On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras < >> > andrewsciber...@pingidentity.com> 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/OAuth2For >> Devices#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 <wdenn...@google.com> >> >> wrote: >> >> >> >>> Hi Andrew, >> >>> >> >>> On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras < >> andrewsciber...@pingidentity.com> 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
