Core 3.1.2.1. - id_token_hint

[Torsten Lodderstedt]

Description of id_token_hint, 2nd sentence states:

"If the End-User identified by the ID Token is logged in or is logged in by the request, then the Authorization Server returns a positive response; otherwise, it SHOULD return an error, such as login_required."

This statement forces the OP to treat the id_token_hint as an essential requirement of the authentication transaction's outcome. This differs substantially from the login_hint's specified behavior. I think either the "hint" suffix is misleading or the text should be softened to allow the OP to also identify another user account. I prefer the latter since this allows the RP to utilize an existing ID token the same way as an e-Mail address as a hint to simplify the login experience.

[Filip Skokan]

If the End-User identified by the ID Token is logged in or is logged in by the request, then the Authorization Server returns a positive response; otherwise, it SHOULD return an error, such as login_required.

This id_token_hint behaviour is desired and already utilized for response_type=none&prompt=none&id_token_hint=... authorization requests to silently detect end-user changes at the upstream IdP.

Also part of https://openid.net/specs/openid-connect-core-1_0.html#rfc.section.3.1.2.2 point 4.

[Torsten Lodderstedt]

I see. In case of response type none, there is no way to convey the user id (to allow the RP to detect the change). Is this widely used?

I nevertheless wanted to point out the misleading name (and more important) the need to provide RPs with a true hint feature based on an ID Token. This is especially useful/needed, if the user account cannot be identified by an e-mail address or MSISDN. This, for example, is the case in the financial sector.

[Filip Skokan]

I see. In case of response type none, there is no way to convey the user id (to allow the RP to detect the change). Is this widely used?

Widely? I'm not sure, but it is used.

I nevertheless wanted to point out the misleading name (and more important) the need to provide RPs with a true hint feature based on an ID Token. This is especially useful/needed, if the user account cannot be identified by an e-mail address or MSISDN. This, for example, is the case in the financial sector.

Agreed.

[gffletch]

I believe the general understanding right now is that if the RP sends an id_token_hint they are expecting to get that identified user back and not some other user.

Changing the semantics seems dangerous at this time.

Would it be possible to use the login_hint field and just send the 'sub' claim of the id_token as the login_hint value and have the OP (by virtual of the client_id in the authorization request and the 'sub' claim) find the user and streamline the login for that user but still allow the user to change to a different identity.

This would match the semantic of login_hint and allow your use case without requiring additional parameters or a change in semantics.

[Torsten Lodderstedt]

I like the idea. The spec allows email and phone number for login_hint right now. Is it possible to extend the text?

Another question: How would the OP differentiate email address/phone number and sub value?

[Filip Skokan]

Send a sub value, OP displays an email or phone nr. , hmm. Wouldn’t that allow some form of scraping or mining user identifiers? For now what is sent is displayed.

Unless the OP masks the actual login identifier I’m not sure about this...

[Torsten Lodderstedt]

Sure, the OP would need to transform the sub into a human readable/understandable identifier. The RP could use that mechanism to scrap in the same way it could scrap any user interaction at the OP.

[gffletch]

The spec says...

login_hint OPTIONAL. Hint to the Authorization Server about the login identifier the End-User might use to log in (if necessary). This hint can be used by an RP if it first asks the End-User for their e-mail 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. This value MAY also be a phone number in the format specified for the phone_number Claim. The use of this parameter is left to the OP's discretion.

So there is no clear distinction between email, phone number or username (used by many OPs). Since the use of the login_hint is left up to the OP I believe the OP can determine how it wants to handle the string. I don't interpret the spec to restrict the hint values to email or phone. If the OP receives a login_hint that doesn't make sense it should just ignore the parameter all together.

[Torsten Lodderstedt]

I think it would be helpful for implementors to mention the option to use a sub value. What do you think?

[gffletch]

Yes, I think if an OP supports an id_token 'sub' claim as a login_hint, mentioning that in the OP documentation makes sense. Currently there are no openid configuration options to allow the OP to even state that it supports login_hint:)

[Torsten Lodderstedt]

I meant mentioning the sub value option in the OIDC spec (beside email and phone number) to make clear this is a viable option and the way this challenge might be solved.

[gffletch]

I guess, I'm not sure that's necessary because the spec currently doesn't mention support for using a "username" which is different from an email address or phone number and yet many OPs do support "username". Any errata or mention would need to be non-normative.

[Torsten Lodderstedt]

Any errata or mention would need to be non-normative.

Sure. One could/should mention the username as well.

[gffletch]

Current text for login_hint: Hint to the Authorization Server about the login identifier the End-User might use to log in (if necessary). This hint can be used by an RP if it first asks the End-User for their e-mail 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. This value MAY also be a phone number in the format specified for the phone_number Claim. The use of this parameter is left to the OP's discretion.

Proposed text for login_hint: Hint to the Authorization Server regarding the End-User that is seeking authentication. The value and meaning of this parameter is left up to the OP's discretion. However, in most common use cases, the value contain an email address, phone number or username collected by the RP before requesting authentication at the OP. As an example, this hint can be used by an RP if it first asks the End-User for their e-mail 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. Other use cases MAY include using the 'sub' claim from the id_token or other hints to the OP about the requested authentication.

[Torsten Lodderstedt]

Looks good!

[Michael Jones]

George's proposed text seems fine to me.

[Michael Jones]

Will be fixed by https://bitbucket.org/openid/connect/pull-requests/579

[Michael Jones]

Fixed by https://bitbucket.org/openid/connect/pull-requests/579