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

Mike Jones <> Thu, 31 May 2018 18:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0D6F12E89D; Thu, 31 May 2018 11:20:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jowfdj9s5ixS; Thu, 31 May 2018 11:20:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E99512E871; Thu, 31 May 2018 11:20:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9Fgd1/1wFel1uGrAOseiZGq4lZ2x+jF8uSjRWfdhwk4=; b=YedCqN92xs6rgaVBqpN/lnVwbqRP6qWnxkGjn21pFVl2t0KaoNi2ri6kQmmc2z6V6efjuPTVToKwCk8exoHpWa+8Dhqil4glEWYpHr3eacz4HdRJ9sQxjySxGseJbtm1jrirUIEBqbk0rSRY4EAc64TvdEg6+A7ZnnADct1cFvk=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.861.0; Thu, 31 May 2018 18:20:14 +0000
Received: from ([fe80::7012:7d9f:583b:e000]) by ([fe80::7012:7d9f:583b:e000%2]) with mapi id 15.20.0862.000; Thu, 31 May 2018 18:20:14 +0000
From: Mike Jones <>
To: Naveen Agarwal <>, William Denniss <>
CC: Brian Campbell <>, "" <>, "" <>, oauth <>, "" <>
Thread-Topic: [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
Date: Thu, 31 May 2018 18:20:14 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-05-31T18:20:11.4981054Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General
x-originating-ip: [2001:4898:80e8:a:c8b7:10f0:56aa:22ce]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN6PR00MB0413; 7:uivY9Oh42c5wlah8yXHKe558sV/+9TFezgjTeffNOFSlG6nJthPMgItHL7x5AATbIVo4366Ybt2BW4JFKJAJwcMzrsPro7AL4YpLcHLrmsHz1BYlGhFatGkNAjnxBe6uCERf7KUSjdWsF6Oae63l2HM5+LuLBlyL/gKt5xDWrFkkAwjq9hLbk8Kge2hWczo77K2kn9JNRtbmHPRkFWDz+8RTWBs0+5262fvTBzw7WDfLsAOBOII8YwMZJi1dMCec; 20:vevqokW4Q7OmQuIaVpMPk91GdokTgHjGz+INrmHn9ueoGHqFy/pRAi0nSL9y/iGhS6IloeuIVrvlV2juDQgmIoIXsE9J57Nt+oO7fJOV2l63CTYteQVfH0BcgRo1ltPt5YlNzhGYsjvK8y2yq7rsPebhcjx85tBjhSHxKHELQiE=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:SN6PR00MB0413;
x-ms-traffictypediagnostic: SN6PR00MB0413:
authentication-results: spf=none (sender IP is );
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(85827821059158)(211936372134217)(153496737603132)(21748063052155)(1591387915157)(168375693250761);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(93006095)(93001095)(3231254)(2018427008)(944501410)(52105095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123560045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:SN6PR00MB0413; BCL:0; PCL:0; RULEID:; SRVR:SN6PR00MB0413;
x-forefront-prvs: 06891E23FB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(39860400002)(39380400002)(376002)(396003)(51444003)(199004)(189003)(46003)(476003)(22452003)(966005)(2900100001)(14454004)(316002)(54906003)(11346002)(110136005)(446003)(229853002)(6436002)(72206003)(478600001)(10290500003)(33656002)(606006)(93886005)(106356001)(55016002)(486006)(7696005)(3280700002)(59450400001)(76176011)(2906002)(53546011)(3660700001)(7736002)(8990500004)(4326008)(5250100002)(10090500001)(25786009)(81156014)(8676002)(81166006)(8936002)(99286004)(6506007)(105586002)(19609705001)(74316002)(186003)(102836004)(68736007)(53936002)(6246003)(86362001)(5660300001)(54896002)(6306002)(236005)(97736004)(9686003)(53376002)(6116002)(790700001)(86612001)(16940595002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR00MB0413;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: XNIWfGqQmWGlzOrSJcMcT9l9jvIMuyIOkaoXKtsHwoxAFWU1ydOix1PGNaOf6fS6pQp+eN+PJNcdwWxXA87iUpE54pbb83Rz4jiPUG4b0QLgcz6AoaVO2+F3s0FrzYr4bVeDXp49fsVllSQ/l5fxPLAX4MleWrVecVm3FXouCuMnlTa+vL3/UhtD1vfrKPrT
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_SN6PR00MB0301BA58FEB996D8BA88373DF5630SN6PR00MB0301namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: df023d0d-ff00-40b0-5466-08d5c723276d
X-MS-Exchange-CrossTenant-Network-Message-Id: df023d0d-ff00-40b0-5466-08d5c723276d
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2018 18:20:14.0891 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR00MB0413
Archived-At: <>
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
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 May 2018 18:20:21 -0000

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: <> On Behalf Of Naveen Agarwal
Sent: Thursday, May 31, 2018 12:39 AM
To: William Denniss <>
Cc: Brian Campbell <>om>;;; oauth <>rg>;
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.



On Wed, May 30, 2018 at 5:06 PM, William Denniss <<>> wrote:

On Wed, May 30, 2018 at 3:48 PM, Brian Campbell <<>> wrote:
I realize this is somewhat pedantic but I don't think referencing
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
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
<> 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 <<>> wrote:

> Hi Andrew,
> On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras <
><>> 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 (
>> /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
> <> 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 <<>>
>> wrote:
>>> Hi Andrew,
>>> On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras <<>> 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<>