[Openid-specs-mobile-profile] login_hint behaviour

Tue Apr 28 10:09:40 UTC 2015

Hi John,

Thanks again for your precise response. It is clear for me that ask for the claim is the solution, so my conclusion is that is necessary that the Identity Provider supports the claims parameter, otherwise the use of login_hint in certain use cases can turn into a security problem.
Best,
Gonza.

From: John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>>
Date: Monday 27 April 2015 17:32
To: "Lodderstedt, Torsten" <t.lodderstedt at telekom.de<mailto:t.lodderstedt at telekom.de>>
Cc: Gonzalo Fernández <gonzalo.fernandezrodriguez at telefonica.com<mailto:gonzalo.fernandezrodriguez at telefonica.com>>, Torsten Lodderstedt <torsten at lodderstedt.net<mailto:torsten at lodderstedt.net>>, "openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>" <openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>>
Subject: Re: [Openid-specs-mobile-profile] login_hint behaviour

The names are relatively clear.  login_hint is a hint to the IdP that can be ignored at the IdP’s discretion.   The IdP could refuse to let the user login but that generally is not considered a good user experience.

login_hint
OPTIONAL. Hint to the Authorization Server about the login identifier the End-User might use to log in (if necessary). This hint can be used by an RP if it first asks the End-User for their e-mail address (or other identifier) and then wants to pass that value as a hint to the discovered authorization service. It is RECOMMENDED that the hint value match the value used for discovery. This value MAY also be a phone number in the format specified for the phone_number Claim. The use of this parameter is left to the OP's discretion.

In the case of id_token_hint.

id_token_hint
OPTIONAL. ID Token previously issued by the Authorization Server being passed as a hint about the End-User's current or past authenticated session with the Client. If the End-User identified by the ID Token is logged in or is logged in by the request, then the Authorization Server returns a positive response; otherwise, it SHOULD return an error, such as login_required. When possible, an id_token_hint SHOULD be present when prompt=none is used and an invalid_request error MAY be returned if it is not; however, the server SHOULD respond successfully when possible, even if it is not present. The Authorization Server need not be listed as an audience of the ID Token when it is used as an id_token_hint value.
If the ID Token received by the RP from the OP is encrypted, to use it as an id_token_hint, the Client MUST decrypt the signed ID Token contained within the encrypted ID Token. The Client MAY re-encrypt the signed ID token to the Authentication Server using a key that enables the server to decrypt the ID Token, and use the re-encrypted ID token as the id_token_hint value.

Because the sub is included in the id_token the IdP SHOULD return an error rather than a different sub.

Remember that unless you are using a signed request tied to the session the user can always tamper with the request.   It is never safe for the client to assume that the sub or hint it asks for is what it gets back.   That leads to real security problems.
(note that the same applies to SAML)

If you are using a request object you can ask for a response that must contain a claim that contains a particular value for “sub”, email or phone.

So login_hint is sufficiently specified, it just may not do what some people are looking for.

Clearly id_token_hint can only be used after the person logs-in the first time.

I think what you may be looking for is the claims request parameter (Sec 5.5)

eg
a claims request like this would return a phone_number claim in the id_token

 {
   "id_token":
    {
     "auth_time": {"essential": true},
     "acr": {"values": ["urn:moderna:iap:silver"] },
     “phone_number”:{“value”:”+16045551212”,"essential": true}
    }
  }

You could also return it from the user_info endpoint as easily.

You may also need to specify that “phone_number_verified”: {“value”:true,"essential": true} .

I note in the bank case if the bank is sending an encrypted login hint then by design it doesn’t know the misden in the hint (otherwise there would be no point in encrypting it), so it can’t know if the user entered a different misden at the IdP.    That is the privacy goal.

If the bank has the users phone number on file to use as a second factor then it should use the direct API interface to get the issuer like a mobile app would do.
The user logs in with there first factor and the bank looks up the number to use and sends it in the claims request, and as the login_hint.

The IdP must return an error if the user doesn’t login to an account that can provide the correct claim.

The client still needs to validate the subject and or the claim value, as an attacker can modify the request.

This did happen to some openid 2 RP who were using email addressees at google and not properly verifying the response and assuming that it was what they requested.

The attacker modified the request in the browser to change it to an account they controlled,  logged in and the RP gets a positive response but didn’t check the value of the email returned.

John B.

On Apr 27, 2015, at 5:42 AM, Lodderstedt, Torsten <t.lodderstedt at telekom.de<mailto:t.lodderstedt at telekom.de>> wrote:

Hi Gonzalo,

it seems to me the semantics of login_hint is not sufficiently enough specified in the core spec. That’s why I asked John for advice. I would recommend we reach out to the OpenID Connect WG and ask for clarification.

Regarding sub/enc login hint: the OpenID Connect core specification neither supports sub nor encrypted login hints. If there is a need to define a respective extension, we should do so. We already had discussions regarding the encrypted login hint and came up with the idea of a new parameter carrying a JWT containing the MSISDN (or whatever is needed) to the OP. That could be a sub as well. Based on a discussion w/ Vodafone we had in the context of the German Trial last week, we (DT&VF) see the need for sub as hint as well.

Best regards,
Torsten.

Von: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] Im Auftrag von GONZALO FERNANDEZ RODRIGUEZ
Gesendet: Montag, 27. April 2015 10:19
An: GONZALO FERNANDEZ RODRIGUEZ; Torsten Lodderstedt; John Bradley
Cc: openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>
Betreff: Re: [Openid-specs-mobile-profile] login_hint behaviour

Even worse,

If the Bank (Service Provider) sends an MSISDN or an encrypted MSISDN (the first time) as login_hint and the OIDC provider prompts the user to enter an MSISDN and he introduces another one, the Service Provider will receive a "sub" that not correspond with the MSISDN that it has.

Best,
Gonza.

De: Gonzalo Fernandez Rodriguez <gonzalo.fernandezrodriguez at telefonica.com<mailto:gonzalo.fernandezrodriguez at telefonica.com>>
Fecha: lunes 27 de abril de 2015 09:57
Para: Torsten Lodderstedt <torsten at lodderstedt.net<mailto:torsten at lodderstedt.net>>, John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>>
CC: "openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>" <openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>>
Asunto: Re: [Openid-specs-mobile-profile] login_hint behaviour

Hi guys,

Thanks a lot for your responses, I still have a doubt…., please consider next use case:

• The "sub" value is supported as login_hint (is something that we were talking last week with Matthieu from Orange).
• A Service Provider use Mobile Connect as a 2nd factor authentication. The Service Provider already know who the user is, probably he/she has been authenticated using another credentials, (banks use case). It sends the login_hint of the user to re-authenticate him to authorize a transaction for example.
• The OIDC provider is not able to realize who the user is (it doens't support this kind of login_hint, or another reason)

If the OIDC prompts the user to enter the MSISDN and he introduces one that is different from the expected with the login_hint provided in the authentication request, the Service Provider will receive a "sub" different from the expected. Could this use case be possible?

Best,
Gonza.

De: Torsten Lodderstedt <torsten at lodderstedt.net<mailto:torsten at lodderstedt.net>>
Fecha: sábado 25 de abril de 2015 18:09
Para: John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>>
CC: Gonzalo Fernandez Rodriguez <gonzalo.fernandezrodriguez at telefonica.com<mailto:gonzalo.fernandezrodriguez at telefonica.com>>, "openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>" <openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>>
Asunto: Re: [Openid-specs-mobile-profile] login_hint behaviour

So far and in contrast to id token hint, I interpreted the login hint as "nice to have but not a strong requirement". The semantics you describe is much stronger. I was unable to find a text in the spec describing the use case we are discussing. Can you refer to some text?

Am 25. April 2015 16:13:07 MESZ, schrieb John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>>:
Sending an error that authentication is needed.  The client needs to retry without prompt=none so the user can sort it out at the AS.

Clients sending users off to reauth need to be able to deal with the case of a different user coming back.

Sent from my iPhone

On Apr 25, 2015, at 5:47 AM, Torsten Lodderstedt <torsten at lodderstedt.net<mailto:torsten at lodderstedt.net>> wrote:

Hi John,

what behavior would you expect if the user id in the login hint conflicts with the user id of the existing session and prompt != none?

Best regards,
Torsten.

Am 24.04.2015 um 23:58 schrieb John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>>:

Agreed.

The exception would be in the prompt=none case where you can’t display a UI.

If the login hint or id_token hint is for a different account than the one with the current session you would need to return a error that authentication is required.

On Apr 24, 2015, at 5:17 PM, Torsten Lodderstedt <torsten at lodderstedt.net<mailto:torsten at lodderstedt.net>> wrote:

Hi Gonzalo,

I would suggest to ignore invalid login_hint values and prompt the user again. As the parameter name suggests, it is just a hint.

best regards,
Torsten.

Am 22.04.2015 um 13:38 schrieb GONZALO FERNANDEZ RODRIGUEZ:
Hi guys,

We are testing our IDGW and we have a doubt about the behaviour that it should be have regarding the authentication in case of a login_hint is provided in the authentication request. Anyone of you can help us in this topic?

If the MNO is not able to resolve who is the user which the login_hint refers to, what should it do? Return an error or prompt the user to introduce its MSISDN?. In case of asking the user for its MSISDN it could happen that the MSISDN is not the same as the one referred by the login_hint (from the Service Provider side).

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.nethttp<mailto:Openid-specs-mobile-profile at lists.openid.nethttp>://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile

_______________________________________________
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

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

________________________________

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/20150428/5a5b413d/attachment-0001.html>