Messages 2.1.1 -- Add login_id hint to authorization request

Issue #646 resolved
gffletch created an issue

Add a hint from the RP to the IdP regarding the user's login id at the IdP.

login_id OPTIONAL. A hint to the authorization service as to the login_id the user may use to authenticate (if necessary). This hint can be used by an RP if it first asks the user for their email 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. The use of this parameter is up to the IdP's discretion.

Comments (9)

  1. Nat Sakimura

    I have a bit of problem with "The use of this parameter is up to the IdP's discretion."

    Suppose Bob started to use Alice's computer. He entered bob@example.com at the site he wanted to access. He then was taken to example.com for authentication. There, Alice's session was still alive. Is the authz server allowed to completely ignore the login_id value and return Bob as Alice? The above sentence seems to allow it. It seems like a security hole.

    Instead, the right approach may be for the IdP to look up the user based on login_id and to find out if the session matches the login_id. If the session is multi-user, then select the one that matches login_id and return the appropriate response.

    What do you think?

  2. gffletch reporter

    I agree that your recommendation is a best practice. I'm just not sure we want to put in the spec all the best practices for IdPs. There are lots of different ways to handle the situation you outline. For instance, the IdP could log Alice out and then log in Bob. Or, the IdP could allow Bob to login and then both Alice and Bob would be logged in at the same time. Or the IdP could present UI to the user asking if they want to log Alice out first, or ignore the login_hint and just continue with Alice.

    I agree that there can be security holes in these sorts of situations, but not having the login_hint makes it worse and the exact implementation should be up to the IdP. Maybe we could add something to the security considerations stating that this could be a problem and IdPs need to handle accordingly?

  3. Michael Jones

    Also, I assume that the semantics of using the parameter user_id=248289761001 are equivalent to making this claim request in the id_token section of the OpenID Request Object: "user_id": {"value":"248289761001"}. Or is it equivalent to the claim request "user_id": {"value":"248289761001", "essential",true}?

  4. John Bradley

    No this is not the user id it is a hint about what name the user is to be prompted with. This is required for account chooser and several other applications.

    We had a fair amount of debate on the list about what to call it.

  5. Log in to comment