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

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> 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
> @aaronpk <http://twitter.com/aaronpk>
>
> ----
> Aaron Parecki
> aaronparecki.com
> @aaronpk <http://twitter.com/aaronpk>
>
>
> On Fri, Oct 21, 2016 at 3:23 PM, Hannes Tschofenig <
> 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.
>>
>> 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
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>