[OAUTH-WG] Device Flow: Alternative to Polling

[Hannes Tschofenig]

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

[Aaron Parecki]

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 <

Post by Hannes Tschofenig
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.
(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
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
https://www.ietf.org/mailman/listinfo/oauth

[William Denniss]

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.

Post by Aaron Parecki
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 <

Post by Hannes Tschofenig
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.
(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
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
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Simon Moffatt]

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.

Post by William Denniss
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.
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
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>.
(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
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
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
ForgeRock <http://www.forgerock.com/> *Simon Moffatt*
OpenAM - Technical Product Manager | ForgeRock
*tel* [phone] | *e* ***@Forgerock.com
<mailto:***@forgerock.com>
*skype* simon.moffatt | *web* www.forgerock.com
<http://www.forgerock.com/> | *twitter* @simonmoffatt



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

[Torsten Lodderstedt]

It would be great to learn more about implementation experiences and
have implementation considerations in this spec.

In the OpenID MODRNA working group, we are working on specs facing
similar challenges and decided to offer both pull and push style
communication (e.g.
https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-user-questioning-api.xml).
If your experience suggests pull is totally sufficient and easier to
implement (esp. for the client), we could also simplify our stuff.

best regards,
Torsten.

Post by Simon Moffatt
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.

Post by William Denniss
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.
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
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>.
(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
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
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
ForgeRock <http://www.forgerock.com/> *Simon Moffatt*
OpenAM - Technical Product Manager | ForgeRock
*skype* simon.moffatt | *web* www.forgerock.com
Summits <https://summits.forgerock.com/>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth