Re: [OAUTH-WG] Device Flow: Alternative to Polling

Simon Moffatt <simon.moffatt@forgerock.com> Mon, 24 October 2016 08:30 UTC

Return-Path: <simon.moffatt@forgerock.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07395129624 for <oauth@ietfa.amsl.com>; Mon, 24 Oct 2016 01:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXKZTyyWR2b4 for <oauth@ietfa.amsl.com>; Mon, 24 Oct 2016 01:30:54 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB90129633 for <oauth@ietf.org>; Mon, 24 Oct 2016 01:30:54 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id c78so90663199wme.0 for <oauth@ietf.org>; Mon, 24 Oct 2016 01:30:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=d51HEThTkSxtohVCtAOGV6KRV487zJeuvcVfiGCHSyY=; b=eEMkyT3J1w+fLvK1l67ltqhpvAPCB0o23Y4nbX2mYD+h+C+Ce5Oj1uRG0Lm89iJbuU 9xYuFf7seW3KaVAQcuUWgJVCnQKNZ74ofRMopD3NzN9DET4EtDfw2xEY9RJr3OPgn4ik MaWFyfRxqu9hgXeQpbCqMPiZr8s6V3BDYqyM8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=d51HEThTkSxtohVCtAOGV6KRV487zJeuvcVfiGCHSyY=; b=N2g9gJujBvidRrn/icjAVUp3F8yPSeZ74eQFdKhmLkNWKMaquz0BzdblFBUhQJTXbb N7P3cX0jwlRfJ+cujT4WKxzTeqdgllyQ6XjIua0PLWP1dwZDzEfjZhrGt3Tkba6zI4fK 9dmJVQeB5wjvdsWmFR17LUXDMOqyccPXiofMvZFB3xEVJKsjtXyOl0fmH/S5bkgJThoC w6oqq+Kkz/KILKyakmo78UmJzrPwPfHDeKU4UpR3m9xrIGfTvbWOJhxQjMco1day7CQ+ CVCsCYQDBi7XpeGaT7NevDIXI52fa44TEV9gLE4fuwNw9gjig4dTKXJrgU4+1aphN8kb rByg==
X-Gm-Message-State: ABUngve82KwYjvM78c+DLq/Fxbjzj01yF4FBRbBfRV9SUmapv4SMaKu6G3o44+hR784Kn3z4b049s1FbJfSSu2dS8/skdTlwoomuYievxUFdXEq77StqJyZgDbmsa8ZypYE5+Sk2FOOnv7Qyd+MxoNA72ITAV8XyPIkbWAakR3QSSxDuCgoT968=
X-Received: by 10.28.170.204 with SMTP id t195mr13143407wme.113.1477297852092; Mon, 24 Oct 2016 01:30:52 -0700 (PDT)
Received: from ?IPv6:2a02:c7f:ba3b:5f00:9d5c:ab4f:3704:1a7f? ([2a02:c7f:ba3b:5f00:9d5c:ab4f:3704:1a7f]) by smtp.gmail.com with ESMTPSA id w1sm17968774wje.36.2016.10.24.01.30.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Oct 2016 01:30:51 -0700 (PDT)
To: William Denniss <wdenniss@google.com>, Aaron Parecki <aaron@parecki.com>
References: <8b540eff-2b1c-2d9f-6d40-2be327f91eb7@gmx.net> <CAGBSGjoO3LiA4NZ9tKrK1KHzBY2MkbfG+XNu_1tnFAptjSnZzQ@mail.gmail.com> <CAAP42hC9SubNrhYeoxPUx2faW_G59yQT0Aqm1U5wRVCcb5Qxfw@mail.gmail.com>
From: Simon Moffatt <simon.moffatt@forgerock.com>
Message-ID: <ac510d94-424c-0ca7-3e4d-b33629124b08@forgerock.com>
Date: Mon, 24 Oct 2016 09:30:49 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <CAAP42hC9SubNrhYeoxPUx2faW_G59yQT0Aqm1U5wRVCcb5Qxfw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------7C27685607EFF2537BE928B8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/K3U8gNWli38dOiNBwDMzGIHj3PE>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Device Flow: Alternative to Polling
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2016 08:30:59 -0000

I agree, simplicity is key here.

 From a practicality perspective (ForgeRock implemented the AS part of 
the device flow in January), there were some steps to mitigate things 
like potential excessive polling and DoS but they can be easily overcome 
on the AS side of things), but as William says, polling is simple and 
solves the use case.

The option of running an HTTP stack on the device, is maybe overkill for 
some deployments though, especially with lower powered devices and the 
management overhead.

Websocket style notifications are gaining popularity for other web 
access management use cases like session destruction notifications and 
session attribute changes so that seems a viable option.


On 21/10/16 23:50, William Denniss wrote:
> We've been operating with polling for a while and handle a decent 
> amount of traffic (the YouTube TV app uses it), the polling gets the 
> job done. The simplicity of the protocol definitely helps when used on 
> constrained devices.
>
> I like the idea of adding HTTP/2 based long-poll as an optional 
> enhancement, especially if we can define it in ways that don't alter 
> the underlying protocol a whole lot.
>
> On Fri, Oct 21, 2016 at 3:35 PM, Aaron Parecki <aaron@parecki.com 
> <mailto:aaron@parecki.com>> wrote:
>
>     Part of the beauty of the current device flow spec is that it's so
>     simple to support. Keeping that simplicity is crucial especially
>     for this, since this flow is used by a variety of devices that
>     often do not have higher level stacks.
>
>     I would love to hear from someone who has experience with
>     large-scale deployments of this to know whether polling is even a
>     problem in the first place.
>
>     ----
>     Aaron Parecki
>     aaronparecki.com <http://aaronparecki.com/>
>     @aaronpk <http://twitter.com/aaronpk>
>
>     ----
>     Aaron Parecki
>     aaronparecki.com <http://aaronparecki.com>
>     @aaronpk <http://twitter.com/aaronpk>
>
>
>     On Fri, Oct 21, 2016 at 3:23 PM, Hannes Tschofenig
>     <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:
>
>         Hi all,
>
>         the device flow document outlines the case when an OAuth
>         interaction
>         gets "outsourced" to a separate device in order to allow user
>         authentication and collecting the consent.
>
>         The exchange is described in Section 1 of
>         https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03
>         <https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03>.
>
>         Here is the step that was raised during the discussions:
>
>               (E) While the end-user authorizes (or denies) the
>         client's request
>               (D), the client repeatedly polls the authorization
>         server to find
>               out if the end-user completed the end-user authorization
>         step.
>               The client includes the verification code and its client
>               identifier.
>
>         The question was whether we could come up with an alternative
>         to polling
>         since this step could potentially take some time. Hence, it
>         would be
>         better if the authorization server has a way to send a message
>         to the
>         client without polling. Of course, the polling frequency
>         matters and how
>         quickly one (e.g., user) wants to know about the successful
>         authorization.
>
>         So, the first question is whether polling is considered as a
>         problem in
>         the first place.
>
>         If so, then the question is how this could be addressed and
>         (from work
>         in other areas) there are really only two approaches:
>
>         1) We make use of some protocol that keeps the connection open
>         and allow
>         asynchronous communication. HTTP/2 and Websockets come to mind.
>
>         2) The client can be addressed through some push notification
>         mechanism,
>         such as by running an HTTP server on the device that can then
>         be used by
>         the authorization server.
>
>         Any views about this topic?
>
>         Ciao
>         Hannes
>
>
>
>         _______________________________________________
>         OAuth mailing list
>         OAuth@ietf.org <mailto:OAuth@ietf.org>
>         https://www.ietf.org/mailman/listinfo/oauth
>         <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/oauth
>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
ForgeRock <http://www.forgerock.com/> 	*Simon Moffatt*
OpenAM - Technical Product Manager  |  ForgeRock
*tel* +44 (0) 7903 347 240  | *e* Simon.Moffatt@Forgerock.com 
<mailto:simon.moffatt@forgerock.com>
*skype* simon.moffatt  | *web* www.forgerock.com 
<http://www.forgerock.com/>  | *twitter* @simonmoffatt



Summits <https://summits.forgerock.com/>