[Openid-specs-mobile-profile] Server Initiation Authentication

John Bradley ve7jtb at ve7jtb.com
Fri Jul 8 16:26:18 UTC 2016


We have two things that we need.

1. Server initiated backchannel authentication.
2. Server initiated backchannel authorization.

To my mind they are related, in both cases the client needs to know exactly who the user is to make the request. 
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.

The difference is really just what is being authorized.

OAuth has server to server flows now,  Resource owner credentials. Client credentials, and JWT assertion.

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.

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.

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.

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.

Adding polling to OAuth is the biggest problem here, but probably applies to both authentication and authorization.

John B.


> On Jun 26, 2016, at 7:37 AM, mobileconnect <gonzalo.fernandezrodriguez at telefonica.com> wrote:
> 
> Hi Guys,
> 
> 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).
> 
> 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.
> 
> 
> 
> 
> SEVER INITIATION AUTH
> 
> 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.
>  
> 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 GET /authroize request and the POST /Token request.
> 
> 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 POST /Token request. To solve this problem I would consider the follow options:
> 
> 
> OPTIONS
> PROS
> CONS
> Extend the Authentication flow with an standard Polling endpoint: 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 
> - Easy to implement
> - Needs a little implementation on the Server (Relay Party)
> - Needs to implement something on the Identity Provider (authenticators or adapters) to  differentiate the server initiated case and not render any HTML.
> - Impact on the RP server performance
> Extend the Authentication flow with Polling redirection: 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.
> - Easy to implement
> - No need any additional implementations or modifications on the 
> - Needs to implement something on the Identity Provider (authenticators or adapters) to  differentiate the server initiated case and not render any HTML.
> - Impact on the RP server performance.
> Headless web-browser: 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: https://github.com/dhamaniasad/HeadlessBrowsers <https://github.com/dhamaniasad/HeadlessBrowsers>.
> - No need any additional implementations or modifications on the Identity Provider nor in the Relay Party
> - They usually have limitations: we would need them to be able to offer an API and 
> New Authentication flow: 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.
> - The Relay Party can receive the token directly without any code interchange.
> - New OAut 2.0 flow. It is necessary to modify an standard.
> - Needs implementation in the server side (Relay Party)
> - Needs implementation in the Identity Provider: the authenticators must be exposed with API’s instead of using redirections.
> 
> 
> Standardising a Polling Endpoint
> 
> 
> <085B653B-16CC-4BC4-AA59-679A185C78ED.png>
> 
> 
> 
> Polling Redirection
> 
> <4FAC7AFE-1DD3-4FFC-BB45-E25D51FA1EF6.png>
> 
> New Oauth 2.0 Flow
> 
> <6BDE2D0D-76E8-425F-8294-2FFF94A22F08.png>
> 
> Best,
> Gonza.
> 
> 
> 
> 
> 
> 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.
> 
> 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.
> 
> 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
> _______________________________________________
> 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/20160708/e98b28bd/attachment-0001.html>


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