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

Torsten Lodderstedt torsten at lodderstedt.net
Mon Dec 5 20:32:58 UTC 2016


Hi,


Am 05.12.2016 um 13:18 schrieb Petteri Stenius:
>
> Hi,
>
> Registration of endpoints is an application level issue, not part of 
> the generalized http level mechanism.
>

but it somehow intervenes with the generic http level mechanism, so the 
generic http part is not self-explanatory.

> With OAuth/OIDC we should follow the convention of registering 
> endpoints with client registration and provider metadata.
>
> The UQ draft defines a new client registration value 
> “client_notification_endpoint” for the callback, but would it not be 
> possible to use “redirect_uris” for this purpose?
>

Do you think this is a good idea to mix the two different modes? The 
rules for processing a conventional redirect (XSRF, referrer header, 
session state/cookies) are different from receiving a server2server 
callback (e.g. IP address black/whitelisting). I would prefer to keep 
them separate.

> The client callback endpoint is an entry in the redirect_uris array of 
> client registration metadata. With a parameter of the request that 
> starts async authentication client indicates at which of the 
> registered endpoints it wishes to receive the async callback. This is 
> comparable to authorization code request.
>
> Petteri
>

best regards,
Torsten.
>
> ------------------------------------------------------------------------
>
> *From:*Torsten Lodderstedt <torsten at lodderstedt.net>
> *Sent:* Saturday, December 3, 2016 10:50:10 AM
> *To:* Petteri Stenius
> *Cc:* openid-specs-mobile-profile at lists.openid.net
> *Subject:* Re: [Openid-specs-mobile-profile] Async authentication with 
> polling and callback
>
> 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 <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
>
>     _______________________________________________
>     Openid-specs-mobile-profile mailing list
>     Openid-specs-mobile-profile at lists.openid.net
>     <mailto: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/20161205/ad440c61/attachment-0001.html>


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