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

mobileconnect gonzalo.fernandezrodriguez at telefonica.com
Sun Jun 26 11:37:59 UTC 2016


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.

- 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


[cid:085B653B-16CC-4BC4-AA59-679A185C78ED]



Polling Redirection

[cid:4FAC7AFE-1DD3-4FFC-BB45-E25D51FA1EF6]

New Oauth 2.0 Flow

[cid:6BDE2D0D-76E8-425F-8294-2FFF94A22F08]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160626/da4a5073/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 085B653B-16CC-4BC4-AA59-679A185C78ED.png
Type: image/png
Size: 154566 bytes
Desc: 085B653B-16CC-4BC4-AA59-679A185C78ED.png
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160626/da4a5073/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4FAC7AFE-1DD3-4FFC-BB45-E25D51FA1EF6.png
Type: image/png
Size: 170834 bytes
Desc: 4FAC7AFE-1DD3-4FFC-BB45-E25D51FA1EF6.png
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160626/da4a5073/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6BDE2D0D-76E8-425F-8294-2FFF94A22F08.png
Type: image/png
Size: 109888 bytes
Desc: 6BDE2D0D-76E8-425F-8294-2FFF94A22F08.png
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160626/da4a5073/attachment-0005.png>


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