<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">We have two things that we need.<div class=""><br class=""></div><div class="">1. Server initiated backchannel authentication.</div><div class="">2. Server initiated backchannel authorization.</div><div class=""><br class=""></div><div class="">To my mind they are related, in both cases the client needs to know exactly who the user is to make the request. </div><div class="">That is different from the front channel where you can send a hint about the user but don’t need to know who they are upfront because the user is in the flow and could select a different account.</div><div class=""><br class=""></div><div class="">The difference is really just what is being authorized.</div><div class=""><br class=""></div><div class="">OAuth has server to server flows now, Resource owner credentials. Client credentials, and JWT assertion.</div><div class=""><br class=""></div><div class="">I think trying to use a browser redirect flow in the back channel is just a bad design, as you get all of the pain and no real benefit other than the AS not needing another endpoint.</div><div class=""><br class=""></div><div class="">I would prefer to have the client make a direct authenticated call to the token endpoint. We have Connect signed requests now that could be reused as a assertion containing the request. That can return AT directly, and that can be used to poll a new endpoint for the response.</div><div class=""><br class=""></div><div class="">One question I have is if there is really a performance benefit to actively polling as opposed to just waiting for the token endpoint call to return.</div><div class=""><br class=""></div><div class="">The other thing that might be possible is to return a refresh token immediately, then the client could use that to poll the token endpoint until a response is available.</div><div class=""><br class=""></div><div class="">Adding polling to OAuth is the biggest problem here, but probably applies to both authentication and authorization.</div><div class=""><br class=""></div><div class="">John B.</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 26, 2016, at 7:37 AM, mobileconnect <<a href="mailto:gonzalo.fernandezrodriguez@telefonica.com" class="">gonzalo.fernandezrodriguez@telefonica.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<title class=""></title>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-family: Calibri, sans-serif; font-size: 14px;" class="">
<div class="">Hi Guys,</div>
<div class=""><br class="">
</div>
<div class="">We agreed to find out a solution for the Server initiation authentication, below you can find a first analyse with some possible solutions to discuss. I have added some diagrams to illustrate them (probably they have some errors).</div>
<div class=""><br class="">
</div>
<div class="">Tomorrow I am travelling to Brazil and I am not sure If I will be able to attend our call, but I will try it.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><b class="">SEVER INITIATION AUTH</b></div>
<div class="">
<div style="font-family: 'Helvetica Neue';" class=""><br class="">
</div>
<div style="font-family: 'Helvetica Neue';" class="">As the authorisation code flow is a flow based on redirections, the client need to be able to follow HTTP redirections, this is something obvious for a web browser and nowadays is not a problem for a server because
there are libraries in almost all the languages able to do it. Just using a parameter (e.g: prompt= RP or prompt= server, …) to indicate to the Identity Provider that the interaction is initiated by a sever will be sufficient to not send any html in the response
to be rendered in the client side.</div>
<span style="font-family: 'Helvetica Neue';" class="">
<div class=""> </div>
<div class="">However the key problem is when the user is being authenticated by the selected authenticator, this interaction happens with a direct call from the client to the authenticator (or adapter), and, as the authentication takes place in a mobile device, it
could takes a long time, what force us to return an HTTP 200 OK response immediately, and ends up in the redirection flow cut. When the client is a web browser this is not a problem because the 200 OK response can contain a body with a javascript code that
will be executed in the browser to continue with the interactions without needing any additional code in the server side, that is, the client is only worried about making the
<b class="">GET /authroize</b> request and the <b class="">POST /Token</b> request.</div>
<div class=""><br class="">
</div>
<div class="">In case we don’t have a web browser in the client side but a server, we need somehow to avoid the communication cut and allow the client (server) to continue with an http flow to be able to receive the final redirection with the code and then get the token
with the <b class="">POST /Token</b> request. To solve this problem I would consider the follow options:</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<table style="border-collapse: collapse; width: 100%; table-layout: fixed; margin-left: 0px; font-size: 14px;" class="">
<tbody class="">
<tr class="">
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;" class="">
<div class="">OPTIONS</div>
</td>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;" class="">
<div class="">PROS</div>
</td>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;" class="">
<div class="">CONS</div>
</td>
</tr>
<tr class="">
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;" class="">
<div class=""><b class="">Extend the Authentication flow with an standard Polling endpoint</b>: we would need to standardise the initial response to an authenticator, returning a TransactionID, (maybe with more parameters like interval, instant, etc) (step 4) when the authenticator
receives the request to authenticate the user. The RP in this case shall poll the ID-GW until it gets a redirection response with the code to get the Token. The ID-GW must also not return </div>
</td>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;" class="">
<div class="">- Easy to implement</div>
</td>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;" class="">
<div class="">- Needs a little implementation on the Server (Relay Party)</div>
<div class="">- Needs to implement something on the Identity Provider (authenticators or adapters) to differentiate the server initiated case and not render any HTML.</div>
<div class="">- Impact on the RP server performance</div>
</td>
</tr>
<tr class="">
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;" class="">
<div class=""><b class="">Extend the Authentication flow with Polling redirection</b>: in this case the ID-GW would return a redirection to automatically poll the result of the authentication, each poll request would return in turn other redirection with another poll request
in case the authentication is still ongoing or with the code to get the Token in case the authentication is already done.</div>
</td>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;" class="">
<div class="">- Easy to implement</div>
<div class="">- No need any additional implementations or modifications on the </div>
</td>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;" class="">
<div class="">- Needs to implement something on the Identity Provider (authenticators or adapters) to differentiate the server initiated case and not render any HTML.</div>
<div class="">- Impact on the RP server performance.</div>
</td>
</tr>
<tr class="">
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;" class="">
<div class=""><b class="">Headless web-browser</b>: use a library in the server side that behaves like a web browser but without graphic interface. Here you can find an exhaust list of them: <a href="https://github.com/dhamaniasad/HeadlessBrowsers" class="">https://github.com/dhamaniasad/HeadlessBrowsers</a>.</div>
</td>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;" class="">
<div class="">- No need any additional implementations or modifications on the Identity Provider nor in the Relay Party</div>
</td>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;" class="">
<div class="">- They usually have limitations: we would need them to be able to offer an API and </div>
</td>
</tr>
<tr class="">
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;" class="">
<div class=""><b class="">New Authentication flow</b>: it would consist of a new Oauth flow to initiate an authorisation request with an HTTP POST request from a backend. The request would be authenticated and it would allow to return the token without needing an intermediate
code.</div>
</td>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;" class="">
<div class="">- The Relay Party can receive the token directly without any code interchange.</div>
</td>
<td style="border-style:solid;border-width:1px;border-color:rgb(219,219,219);padding:10px;margin:0px;width:33.33%;" class="">
<div class="">- New OAut 2.0 flow. It is necessary to modify an standard.</div>
<div class="">- Needs implementation in the server side (Relay Party)</div>
<div class="">- Needs implementation in the Identity Provider: the authenticators must be exposed with API’s instead of using redirections.</div>
</td>
</tr>
</tbody>
</table>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><b class="">Standardising a Polling Endpoint</b></div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><span id="cid:085B653B-16CC-4BC4-AA59-679A185C78ED"><085B653B-16CC-4BC4-AA59-679A185C78ED.png></span></div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><b class="">Polling Redirection</b></div>
<div class=""><br class="">
</div>
<div class=""><span id="cid:4FAC7AFE-1DD3-4FFC-BB45-E25D51FA1EF6"><4FAC7AFE-1DD3-4FFC-BB45-E25D51FA1EF6.png></span></div>
<div class=""><br class="">
</div>
<div class=""><b class="">New Oauth 2.0 Flow</b></div>
<div class=""><br class="">
</div>
<div class=""><span id="cid:6BDE2D0D-76E8-425F-8294-2FFF94A22F08"><6BDE2D0D-76E8-425F-8294-2FFF94A22F08.png></span></div>
</span></div>
<div class=""><br class="">
</div>
<div class="">Best,</div>
<div class="">Gonza.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<br class="">
<hr class="">
<font face="Arial" color="Gray" size="1" class=""><br class="">
Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la
lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.<br class="">
<br class="">
The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.<br class="">
<br class="">
Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a
leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição<br class="">
</font>
</div>
_______________________________________________<br class="">Openid-specs-mobile-profile mailing list<br class=""><a href="mailto:Openid-specs-mobile-profile@lists.openid.net" class="">Openid-specs-mobile-profile@lists.openid.net</a><br class="">http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile<br class=""></div></blockquote></div><br class=""></div></body></html>