[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