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

[Torsten Lodderstedt]

Hi Petteri,

thanks for your proposal.

One question popped up when I read the sequence for the callback case: how does the server know where to send the callback in step 3?

best regards,
Torsten.

> Am 01.12.2016 um 16:58 schrieb Petteri Stenius <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
>  
>  
> _______________________________________________
> Openid-specs-mobile-profile mailing list
> Openid-specs-mobile-profile at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20161203/ce3cfb5d/attachment-0001.html>