[Openid-specs-ab] Limiting a login request to a specific user

John Bradley ve7jtb at ve7jtb.com
Wed Sep 24 20:37:24 UTC 2014


Yes, however in conversation with Mike it appears that they are wanting to scope the login to an alias for the user and not the user_id itself, so that method likely won't work for them.

They seem to be looking to limit the returned value to a alias of the hint.

That presents a issue given that the hint might cover all the users at the idp or some group etc. 
So defining the exact semantics of how a exact match on something that is otherwise treated as a hint may be tricky.

John B.
On Sep 24, 2014, at 5:41 AM, Nat Sakimura <n-sakimura at nri.co.jp> wrote:

> Hi Takahiro, 
> 
> You are right. You would have to state the 'iss' as well though and add 'essential' to them as well. 
> 
> This actually has been discussed in the following thread back in 2012. 
> 
> http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120903/002354.html
> 
> In the mail, Blaine expressed the requirement as: 
> 
>> Only sign in the user identified by user_id. If it's not possible to 
>> sign in that user, please return an error.
> 
> The response to the message by John B. was: 
> 
>> We have the only sign in this  user_id  in the request object already.
> 
> and the example is given in http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120903/002367.html
> 
> Taking the example, the request object for requesting a specific sub would be: 
> 
> {
> "response_type": "code id_token",
> "client_id": "s6BhdRkqt3",
> "redirect_uri": "https://client.example.org/cb",
> "scope": "openid profile",
> "state": "af0ifjsldkj",
> "userinfo":
>   {
>     "claims":
>       {
>         "name": {"essential": true},
>         "nickname": null,
>         "email": {"essential": true},
>         "email_verified": {"essential": true, "value": true},
>         "picture": null
>       }
>   },
> "id_token":
>   {
>     "claims":
>       {
>         "iss": {"essential": true, "value": "https://op.example.com/"},
>         "sub": {"essential": true, "value": "1352468"},
>         "auth_time": {"essential": true},
>         "acr": { "values":["2"] }
>       },
>     "max_age": 86400
>   }
> }
> 
> 
> 
> 
> The conclusion of the WG was that 
> 
> On Tue, 23 Sep 2014 19:57:46 +0900
> Takahiko Kawasaki <daru.tk at gmail.com> wrote:
> 
>> "OpenID Connect Core 1.0, 3.1.2.2. Authentication Request Validation"
>> says as follows:
>> 
>>> If the sub (subject) Claim is requested with a specific value
>>> for the ID Token, the Authorization Server MUST only send a
>>> positive response if the End-User identified by that sub value
>>> has an active session with the Authorization Server or has been
>>> Authenticated as a result of the request. The Authorization
>>> Server MUST NOT reply with an ID Token or Access Token for a
>>> different user, even if they have an active session with the
>>> Authorization Server. Such a request can be made either using
>>> an id_token_hint parameter or by requesting a specific Claim
>>> Value as described in Section 5.5.1, if the claims parameter is
>>> supported by the implementation.
>> 
>> Doesn't this mechanism suit your case?
>> 
>> If my understanding is correct, a client application can request
>> a specific subject (login ID) using "claims" request parameter
>> like below.
>> 
>>    {
>>     "id_token":
>>       {
>>         "sub": {"value": "REQUIRED-SUBJECT"}
>>       }
>>    }
>> 
>> If I'm wrong, please let me know, experts.
>> 
>> Takahiko Kawasaki
>> 
>> 2014-09-23 7:34 GMT+09:00 Tim Bray <tbray at textuality.com>:
>>> Cleanest way would probably be new parameters “login_must_be” /
>>> ”id_token_must_be”, same semantics as login_hint but substitution
>>> forbidden.
>>> 
>>> On Mon, Sep 22, 2014 at 3:26 PM, Mike Jones
>>> <Michael.Jones at microsoft.com> wrote:
>>>> 
>>>> We have a use case in which we want to limit the login to the user
>>>> specified via the login_hint and not allow the user to sign in as a
>>>> different user.  How would you suggest expressing that
>>>> requirement?  For instance, should we invent a new request
>>>> parameter such as “this_user=true” (which could be used in
>>>> combination with login_hint or id_token_hint)?  Or might a
>>>> “prompt” parameter value such as “prompt=this_user” be
>>>> appropriate? Or would that possibly conflict with other uses of
>>>> “prompt”?
>>>> 
>>>> 
>>>> 
>>>>                                                                --
>>>> Mike
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> - Tim Bray (If you’d like to send me a private message, see
>>> https://keybase.io/timbray)
>>> 
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> 
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 
> 
> -- 
> Nat Sakimura (n-sakimura at nri.co.jp)
> Nomura Research Institute, Ltd. 
> 
> PLEASE READ:
> The information contained in this e-mail is confidential and intended
> for the named recipient(s) only. If you are not an intended recipient
> of this e-mail, you are hereby notified that any review, dissemination,
> distribution or duplication of this message is strictly prohibited. If
> you have received this message in error, please notify the sender
> immediately and delete your copy from your system.
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- 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-ab/attachments/20140924/584e87be/attachment.p7s>


More information about the Openid-specs-ab mailing list