[Openid-specs-mobile-profile] login_hint behaviour

John Bradley ve7jtb at ve7jtb.com
Tue Apr 28 13:40:03 UTC 2015


Yes,

Sorry I probably missed the !=.

If the session is interactive the user may be prompted to switch accounts based on the hint,  but if they don’t they can authenticate with a different account, or use an existing session.

The Client always needs to check the response.  There is no assumption that there is a one to one mapping of the hint to subject,  hints may be reassigned etc.

The id_token hint is about the sub and that SHOULD return an error if the subs of the existing session or a new session doesn’t match.  
The client MUST always check the sub in the response, as the request could be tampered with in the browser.

Someone probably had some use case that prevented the id_token_hint from being a MUST,  but I don’t remember what it was off the top of my head.

John B.


> On Apr 28, 2015, at 8:54 AM, Lodderstedt, Torsten <t.lodderstedt at telekom.de> wrote:
> 
> Hi John,
>  
> so I probably got your earlier posting wrong.
>  
> I asked “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?”
>  
> You answered:
> “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.”
>  
> Now you are saying “login_hint is a hint to the IdP that can be ignored at the IdP’s discretion.”
>  
> My bottom line is: the OP may ignore the conflict and return the user id of the existing session to the client.
>  
> Correct?
>  
> best regards,
> Torsten.
>  
> Von: John Bradley [mailto:ve7jtb at ve7jtb.com] 
> Gesendet: Montag, 27. April 2015 17:33
> An: Lodderstedt, Torsten
> Cc: GONZALO FERNANDEZ RODRIGUEZ; Torsten Lodderstedt; openid-specs-mobile-profile at lists.openid.net
> Betreff: 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 <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://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile <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 <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20150428/b1950674/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4326 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20150428/b1950674/attachment-0001.p7s>


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