[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