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

Nat Sakimura n-sakimura at nri.co.jp
Wed Sep 24 08:41:04 UTC 2014


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.


More information about the Openid-specs-ab mailing list