[Openid-specs-mobile-profile] Notes from Moderna Aug 24
Torsten Lodderstedt
torsten at lodderstedt.net
Mon Sep 5 18:30:27 UTC 2016
Hi all,
I personally would prefer to have a dedicated, new endpoint for
initializing a backchannel authentication transaction, like the OAuth
device flow does
(https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03). I
consider this the cleanest and easiest way (for both OP and client
implementors) to solve our use case. It would allow us to define
parameters and processing rules in a way suitable for backchannel
authentication (without imposing limitations/constraints originating
from frontchannel authentication onto implementors).
I see the following properties of the backchannel authentication endpoint:
- HTTP method POST (only), parameters are sent in the request body
- supports client authentication (which the authz endpoint does not!)
using client secret or JWT assertions
- utilizes existing OAuth/OIDC authorization/authentication requests
parameters as needed, such as "scope" (but not "redirect_uri" or
"response type")
- adds further parameters needed for backchannel authentication, such as
"callback" or "client_notification_endpoint"
- returns auth_req_id
If we want to offer pull style processing, we could (again) follow the
pattern proposed by the OAuth device flow and introduce a new grant type
to the tokens endpoint for that purpose (e.g.
"urn:openid:params:modrna:grant-type:backchannel_request"). The client
would use this grant type along with the "auth_req_id" to query the
results of the authentication transaction.
best regards,
Torsten.
Am 02.09.2016 um 22:03 schrieb John Bradley:
> I would base it on the RFC 7523 Authorization grant. Using a self
> signed Connect Request Object as the grant request.
>
> The IdP performs the out of band consent to approve the grant request.
>
> If the request is signed the RP could specify any URI it likes as a
> post back location if you are not polling or blocking.
>
> I think this method may allso would allow for the the collection of
> consent for transactions.
>
> I would prefer not to wind up with two separate extensions for
> backchannel authentication (Really consent to login as it is not
> authenticating the front channel) and consent for transactions.
>
> John B.
>> On Sep 2, 2016, at 4:33 PM, GONZALO FERNANDEZ RODRIGUEZ
>> <gonzalo.fernandezrodriguez at telefonica.com
>> <mailto:gonzalo.fernandezrodriguez at telefonica.com>> wrote:
>>
>> Hi again John,
>>
>> Is true the the RO credentials flow authenticate the user, but in
>> this case the RP knows the user credentials (user/password) and it is
>> not your case, we only knows the MSISDN and we need somehow to
>> specify an ac_value to authenticate the user, we would also need to
>> extend it.
>>
>> If I understand well, what you propose is not sending the parameters
>> in the POST’s body in clear but send a GET with a unique parameter
>> that is a signed JWT, it could be send to the Token endpoint or to
>> another endpoint. Let’s say we use the Token endpoint, whenever a
>> request is received is should….
>>
>> * Checks the sign
>> * generates the auth_req_id and
>> * sends a response to the RP with the auth_req_id to allow the RP
>> polling for the authentication response
>> * select the authenticator to authenticate the user, generate
>> tokens and send them as the poll response…..
>>
>>
>> P.S: is there any place where the attacks to the redirect_ui with
>> parameters are documented?
>>
>> Best,
>> Gonza.
>>
>> From: John Bradley
>> Date: Friday 2 September 2016 at 19:53
>> To: Gonzalo Fernández
>> Cc: Torsten Lodderstedt, Openid-specs-mobile-profile
>> Subject: Re: [Openid-specs-mobile-profile] Notes from Moderna Aug 24
>>
>> The token endpoint is used to authenticate the user in several flows.
>>
>> Most notably the RO Credentials flow that is unfortunately widely used.
>>
>> I personally still think that this use case is much closer to the JWT
>> assertion flow that uses the token endpoint and is used by many API
>> providers like Google.
>>
>> In that case the client would create a signed JWT Connect request
>> object, and send that to the token endpoint. It could then wait for
>> a reply or get a response and poll.
>>
>> We did discuss that option at the last face to face meeting.
>>
>> To your question yes we could create a new response mode like
>> “direct" that would return the response in the body like we do from
>> the token endpoint for responses.
>>
>> I do think that eliminating the registered redirect forces us to
>> consider signed requests, so that we are not creating new security
>> issues.
>>
>> It is the openID core spec that requires exact redirect URI matching.
>> Anything else is a violation of the spec.
>>
>> The OAuth allows query parameters to be excluded from the match for
>> the code flow.
>>
>> There have been some large number of attacks that take advantage of
>> pattern matching.
>> The OAuth WG is likely going to recommend that RP create a IdP
>> specific redirect URI and that the IDP must do exact matching on it.
>>
>> This was one of the outcomes of the OAuth security conference in July.
>>
>> John B.
>>
>>> On Sep 2, 2016, at 2:25 PM, GONZALO FERNANDEZ RODRIGUEZ
>>> <gonzalo.fernandezrodriguez at telefonica.com
>>> <mailto:gonzalo.fernandezrodriguez at telefonica.com>> wrote:
>>>
>>> Hi Torsten,
>>>
>>> I get you, however I don’t see such problem. It is true that the
>>> current flows are based on redirections, but it doesn’t mean that is
>>> necessary to have another different endpoint. What is the reason? Is
>>> it some consistency in the design?
>>>
>>> For me the endpoint is only an entry point and it should have a
>>> decoupled implementation depending on the flow to follow. If you
>>> consider the semantic is more clear for the RP to use the endpoint
>>> authorise instead of using the token endpoint, follow your same
>>> argument, the token endpoint has not been designed to authenticate
>>> the user, I don’t see it as candidate. I don’t mine to use another
>>> different endpoint if we consider that is a better design.
>>>
>>> Best,
>>> Gonza.
>>>
>>> From: Torsten Lodderstedt
>>> Date: Friday 2 September 2016 at 18:15
>>> To: Gonzalo Fernández, John Bradley, Openid-specs-mobile-profile
>>> Subject: Re: [Openid-specs-mobile-profile] Notes from Moderna Aug 24
>>>
>>> Hi Gonzalo,
>>>
>>> I'm a bit confused about the discussion about response mode vs
>>> response type vs scope because I understand why the client is
>>> supposed to send the requests to the authorization endpoint. This
>>> endpoint is explicitely designed for redirect-based frontchannel
>>> flow, the exact opposite from what we are talking about in the
>>> context of backchannel authentication. The current proposal also
>>> does not comply with the current authz response.
>>>
>>> I think it would be a better solution to either send the first
>>> request to the tokens endpoint or (even better) to use a distinct
>>> (new) endpoint to initialize the process.
>>>
>>> best regards,
>>> Torsten.
>>>
>>> Am 02.09.2016 um 15:35 schrieb GONZALO FERNANDEZ RODRIGUEZ:
>>>> Hi John,
>>>>
>>>> First of all many thanks for the minutes.
>>>>
>>>> The las Wednesday we were talking about this draft in the GSMA
>>>> meeting with operators and Mickäel Vasselet from Orange suggested
>>>> to use the response_mode instead of the scope value openidserver
>>>> for signalling the flow. I read the spec and it says
>>>>
>>>> response_mode
>>>> OPTIONAL. Informs the Authorization Server of the mechanism to
>>>> be used for returning parameters from the Authorization
>>>> Endpoint. This use of this parameter is NOT RECOMMENDED when
>>>> the Response Mode that would be requested is the default mode
>>>> specified for the Response Type.
>>>>
>>>>
>>>> In our last call, John suggested to use a new response_type instead
>>>> of a scope value, so I think we can define a default mode for the
>>>> new response_type that returns id_token and access_token. Is this
>>>> ok?, Anyone would like suggesting a name for the new response_type?
>>>>
>>>>
>>>> Best,
>>>> Gonza.
>>>>
>>>> From: Openid-specs-mobile-profile
>>>> <openid-specs-mobile-profile-bounces at lists.openid.net
>>>> <mailto:openid-specs-mobile-profile-bounces at lists.openid.net>> on
>>>> behalf of John Bradley <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>>
>>>> Date: miércoles, 24 de agosto de 2016, 19:03
>>>> To: Openid-specs-mobile-profile
>>>> <openid-specs-mobile-profile at lists.openid.net
>>>> <mailto:openid-specs-mobile-profile at lists.openid.net>>
>>>> Subject: [Openid-specs-mobile-profile] Notes from Moderna Aug 24
>>>>
>>>>
>>>>
>>>> Bjorn
>>>> Gonzalo
>>>> Nat
>>>> James
>>>> Shiva
>>>> Mohajeri
>>>> John
>>>>
>>>>
>>>> September WS we need agenda and info to book hotels.
>>>>
>>>> Gonzalo Back channel draft.
>>>> New version uploaded last week.
>>>> https://bitbucket.org/openid/mobile/src/75eae8b8e50737059c069965c8c37e794843b510/draft-mobile-client-initiated-backchannel-authentication-01.html?at=default&fileviewer=file-view-default
>>>>
>>>>
>>>> Need discussion on the auth_req_id vs dymamic redirect_uri for
>>>> post response
>>>>
>>>> Need discussion on defining a new response_type vs a scope for
>>>> signalling the flow.
>>>>
>>>> Long discussion on poling response vs Post push.
>>>>
>>>> We discussed the similarity with the device flow that uses long
>>>> polling and may be updated to support out of band push for
>>>> consent/authentication rather as well as the current type the URI
>>>> method.
>>>> https://tools.ietf.org/html/draft-ietf-oauth-device-flow
>>>>
>>>> John observed that polling may be easier logic for some RP to
>>>> implement, and can work with non server devices.
>>>> Posting back to the client also introduces new security
>>>> considerations, if mutual TLS is not used.
>>>> The whole response may need to be signed eg include the auth_req_id
>>>> inside the id_token.
>>>> Connect is defining Session ID “sid” as part of logout, that might
>>>> be something we could use instead of auth_req_id to correlate in
>>>> the POST case, as it will be a id_token claim.
>>>>
>>>> Shiva is going to get feedback from operators on the backchannel
>>>> draft and circulate to the WG.
>>>>
>>>> John B.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> 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.nethttp://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> 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
>>
>>
>> ------------------------------------------------------------------------
>>
>> 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/20160905/fde61273/attachment-0001.html>
More information about the Openid-specs-mobile-profile
mailing list