[Openid-specs-mobile-profile] Async authentication with polling and callback

GONZALO FERNANDEZ RODRIGUEZ gonzalo.fernandezrodriguez at telefonica.com
Fri Dec 9 10:40:44 UTC 2016


Hi guys,

I have been thinking again about Polling proposal and doing a thorough examination I don’t really see too much advantages. These are my thoughts on this:


  1.  Retry-After sounds good to me, but thinking a bit more I am wondering: How does the server know when it will be free to respond?. I think that retrying mechanisms are more effective when they are implemented in the client side. The current draft defines “interval” as  the minimun amount of time in seconds that the client SHOULD wait between polling requests. The client can even wait more if after some retries it realize that it takes too long the server to respond.
  2.  Consistency is very important, the “interval” in body response already exist in https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03. We should take care of all our specs doing same things in the same way.
  3.  303 Redirect: I don’t thnk you have a problem with redirection limits because it only affect to nested redirections and this is not the case right?, However if you put yourself in programmer’s shoes is likely better to know when your request is failing exactly and not to loose sight of it with this kind of magic.

Best,
Gonza.

From: Openid-specs-mobile-profile <openid-specs-mobile-profile-bounces at lists.openid.net<mailto:openid-specs-mobile-profile-bounces at lists.openid.net>> on behalf of "Manger, James" <James.H.Manger at team.telstra.com<mailto:James.H.Manger at team.telstra.com>>
Date: viernes, 9 de diciembre de 2016, 2:51
To: Petteri Stenius <Petteri.Stenius at ubisecure.com<mailto:Petteri.Stenius at ubisecure.com>>, "openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>" <openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>>
Subject: Re: [Openid-specs-mobile-profile] Async authentication with polling and callback

A more general http polling mechanism is appealing, but this one isn’t quite right.

Returning “Retry-After: 10” means a (compliant) app won’t check for 10s so the user will be waiting for up to 10s for the app to respond. That is a very bad experience. We should require servers to support long polling instead (eg server waits for up to 10s before responding; if there is no final answer yet, then the app immediately makes another request).

A sequence of 303 redirects for each polling call is cute (an app follows redirects without even realizing it is polling). But it is too likely to fail as HTTP clients typically have limits on how many redirects they will follow to stop infinite redirect loops. This might warrant a new 3xx status code, eg “308 Poll”, that apps know may require many calls (but at a slow pace, eg 1 every 10s).

308 Poll
Indicates that a response is not yet available, but the client can poll for it by making a GET request to the address in the Location header. The server MUST support long polling at that address if the response does not include a Retry-After header. A subsequent 308 to a polling request indicates a continuation of the same original request.”

--
James Manger


Am 01.12.2016 um 16:58 schrieb Petteri Stenius <Petteri.Stenius at ubisecure.com<mailto:Petteri.Stenius at ubisecure.com>>:
Hello everybody

At the Paris meeting in September there was some discussion about polling and callback mechanisms related to asynchronous functions.

These mechanisms exist in both UQ and SIBA draft specifications. Polling is also defined in OAuth Device Flow draft.

This proposal is an attempt to generalize async polling and callback mechanisms:


·         Define polling on the http level, not an application level function

·         Callback is only a simple notification request, a client initiated request is required to fetch the actual content

The two proposals work together, and make for example switching between polling and callback mechanisms very easy.

Thanks,
Petteri


Polling defined on the http level

Define mechanism with HTTP 303 redirect and Retry-After response header.

303 redirect is used to define polling as sequence of http redirects the client follows until async operation completes and response appears.
The client MUST wait time indicated by Retry-After header before following a redirect. Failing to do so would result in 503 Service Unavailable error (with Retry-After header).
Semantics is comparable to "Wait a moment, the response will soon appear at this location"

The server is allowed to implement "long polling" by holding a response up to 30 seconds (see https://tools.ietf.org/html/rfc6202#section-5.5)

Example of polling sequence:


1.       Client begins async operation

POST /begin-async-operation HTTP/1.1


2.       Server response with 303 status indicates client must begin polling for response. Server encodes state into querystring of redirect uri

HTTP/1.1 303 See Other
Location: /async-response?opaque-server-state-1
Retry-After: 10


3.       Client waits at least 10 seconds before following the redirect

GET /async-response?opaque-server-state-1 HTTP/1.1


4.       Server response with new uri where querystring has changed

HTTP/1.1 303 See Other
Location: /async-response?opaque-server-state-2
Retry-After: 10


5.       Client again waits before following the redirect

GET /async-response?opaque-server-state-2 HTTP/1.1


6.       Server response with content when async operation has completed

HTTP/1.1 200 OK

"completed"


Callback is a simple notification request

My proposal for callback mechanism is a simple notification request.
Server encodes any state it needs into querystring of the notification request.
For the client the querysring is opaque and the client must pass it as-is when fetching the actual content from the server.
Using a simple notification request removes the requirement for client to authenticate the callback request from server.

Example of callback sequence:


1.       Client begins async operation

POST /begin-async-operation HTTP/1.1


2.       Server response with 202 status indicates client needs to wait for callback

HTTP/1.1 202 Accepted


3.       When async operation completes server sends a notification request to client. Server encodes state into querystring of notification uri

GET /callback?opaque-server-state-3 HTTP/1.1


4.       Client response is not processed by server

HTTP/1.1 204 No Content


5.       Client creates request uri and fetches content from server

GET /async-response?opaque-server-state-3 HTTP/1.1


6.       Server response with content

HTTP/1.1 200 OK

"completed"



Related discussion

[Openid-specs-mobile-profile] Async authentication
http://lists.openid.net/pipermail/openid-specs-mobile-profile/Week-of-Mon-20161010/000615.html

[OAUTH-WG] polling in the device flow
https://www.ietf.org/mail-archive/web/oauth/current/msg02939.html

[OAUTH-WG] Device Flow: Alternative to Polling
https://www.ietf.org/mail-archive/web/oauth/current/msg16723.html

References

OAuth 2.0 Device Flow
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03

HTTP/1.1 Semantics and Content
https://tools.ietf.org/html/rfc7231

Retry-After
https://tools.ietf.org/html/rfc7231#section-7.1.3

Best Practices for the Use of Long Polling
https://tools.ietf.org/html/rfc6202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20161209/96eee9c2/attachment-0001.html>


More information about the Openid-specs-mobile-profile mailing list