Messages add id_token to Authorization Request

[John Bradley]

Currently all Authorization requests are directed requests. The Authorization server must ask the user who they are unless they have an existing session.

Sending the id_token in the request provides evidence to the IdP that the user has previously logged in. Allowing the IdP to prompt the user with the correct ID or directly return a response if the user has persistently authorized the scopes for the client.

Currently if the user is logged into site A with ID User_1 but now logs in to the IdP with a second account User_2 and the IdP performs a request to the authorization server with prompt=none the IdP might reply with the ID User_2 if it has been used there before and perhaps leaking information about the linkage of the accounts.

I am uncomfortable about sending prompt=none without a user_id. I think it has uses being optional on all requests, but required for prompt=none.

This is equivalent to openid 2.0 openid.mode=checkid_imediate, That required a claimed_id in the request.

John

[Former user]

OpenID 2.0 allows for a directed response in immediate mode by allowing for the identifier_select URL to be passed as the identity field (section 9.1). This use case makes the most sense if your IdP is tied into another SSO system, and it allows you to do an SSO style flow using OpenID as the transport.

I'm fine with having the id_token optionally passed as one of the fields, but it only helps the case where you've got a single site trying to log in a user multiple times. It doesn't help in the case where a user has typed in an identifier ([e-mail]), since you won't have a valid id_token to pass along. It also doesn't help with a user logging in to Site A, somebody switching the account at the IdP, then logging in to Site B. In that case, they'd still get logged in as User 2.

Passing a (potentially untrusted) user identifier, if available, makes more sense to me than a full blow id_token in these cases.

[Nat Sakimura]

There are two cases:

1. has this user given me the permission to be tacitly log in?
2. Is this user still logged in?

For the later, id_token would be required. For the former, no.

So requiring is overkill.

[Michael Jones]

Breno believes that the ability to pass an id_token with any authorization request enhances the session management possibilities. This is a hint - not a credential. The working group agrees with a SHOULD when used with prompt:none. It is optional with other requests. The OP may correlate the client ID to the ID token. Given that it is a hint, the OP may accept expired ID tokens. If it's not an immediate mode request, mismatch need not be a failure, as the user may choose a specific account different than the one in the id_token.

[John Bradley]

Fixes #535 Added id_token to authorization request paramaters

→ da0c97b18922

[Ryo Ito]

When RP builds Authorization Request using OpenID Request Object, id_token member may be already used as defined at 2.1.2.1.2.

Does Authorization Request include a value of id_token in only a query parameter?

[John Bradley]

You can send a id_token that came from the Authorization server back to the authorization server as a query parameter to be used as a hint about what user should be authenticated.

That is in addition to the claims requested as part of the if_token member of the request_object.

So if you only want a specific user to authenticate you can do it ether way.

[Ryo Ito]

I understood the purpose of this parameter.

When I want to add the value of id_token into following Request Object, how do I insert it?

{
 "response_type": "code id_token",
 "client_id": "s6BhdRkqt3",
 "prompt": "none",
 "redirect_uri": "https://client.example.com/cb",
 "scope": "openid profile",
 "state": "af0ifjsldkj",
 "userinfo":
   {
     "claims":
       {
         "name": null,
         "nickname": {"optional": true},
         "email": null,
         "verified": null,
         "picture": {"optional": true}
       }
   },
 "id_token":
   {
     "claims":
       {
        "auth_time": null,
        "acr": { "values":["2"] }
       },
     "max_age": 86400,

   }
}

Is id_token Claims necessary?

{
 "response_type": "code id_token",
 "client_id": "s6BhdRkqt3",
 "redirect_uri": "https://client.example.com/cb",
 "prompt": "none",
 "scope": "openid profile",
 "state": "af0ifjsldkj",
 "userinfo":
   {
     "claims":
       {
         "name": null,
         "nickname": {"optional": true},
         "email": null,
         "verified": null,
         "picture": {"optional": true}
       }
   },
 "id_token":
   {
     "id_token": {"value":"e...(ID Token)..."}, 
     "claims":
       {
        "auth_time": null,
        "acr": { "values":["2"] }
       },
     "max_age": 86400,

   }
}

[Former user]

The following scenario seem unsupported, is it intentional?

1) client sends the authorization request / id_token field as a hint for authentication, as described in this ticket, and

2) client also wants to request additional claims through the request object / id_token member

Messages/2.1.2.1 OpenID Request Object mandates that:

"All parameter values that are present both in the OAuth 2.0 Authorization Request and in the OpenID Request Object MUST exactly match."

This will always fail in this scenario since 1) is an ID Token (response) while 2) is an ID Token request, having different formats.