Messages 2.1.1.1 Define "negative response" for id_token_hint

[Vladimir Dzhuvinov]

Hi guys,

id_token_hint : The spec says that the server SHOULD return a "negative response" if the required subject isn't logged in. We have found out that for proper client / server interop there has to be an agreed error code for that.

The base OAuth 2.0 "access_denied" error is one possible candidate for that, but is too general.

The OIDC error "login_required" seems more specific, and it also ties nicely with the (common?) id_token_hint case when it is used with prompt=none.

Finally, what error should the server return if prompt=none and the server's policy expects an id_token_hint, but it is missing in the authz request? invalid_request?

What are the security implications of not requiring an id_token_hint with prompt=none?

Thanks,

Vladimir

[Michael Jones]

It seems that we should define what error codes to return for these cases. What are people currently doing?

[Michael Jones]

I believe there's consensus to use the "login_required" and "invalid_request" error codes, as described in Vladimir's report. I believe there's also consensus that OPs should try to not fail when an id_token_hint is not provided, whenever possible.

[Nat Sakimura]

I suppose proposed text would probably be like:

**OPTIONAL. Previously issued ID Token passed to the Authorization Server as a hint about the End-User's current or past authenticated session with the Client. This is often used with prompt=none, but the server SHOULD NOT fail even if this parameter was not available.

If the request is valid and 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 either "login_required" response. The Authorization Server need not be listed as an audience of the ID Token when it is used as an id_token_hint value. **

Re: security implication of not sending id_token_hint:

If the user has no session at the server, the server will return error. If the user has a session at the server, the server may return the user with a positive response without the user noticing. It may thus constitute a privacy leakage.

From the privacy perspective, the server should not return the positive response unless the user has previously consented explicitly or implicitly to be logged into the client without prompting. So, to enable it, the server has to ask the user "Do you want to login automatically to this site?" at the first time the user was logging in.

We could add this to the privacy consideration, though it has no normative impact to the protocol.

[Vladimir Dzhuvinov]

Thanks Mike, thanks Nat. We'll now make sure we use login_required for the negative condition.

[Michael Jones]

Fixed #878 - Defined negative response for "id_token_hint"

→ <<cset 492cb665f860>>

[Michael Jones]

In his review, Brian Campbell pointed out that errors other than login_required are likely appropriate in some failing prompt=none cases, for instance interaction_required, consent_required., and session_selection_required He proposed that we generalize the text accordingly. I think he's right.

We could either go back to just saying that an error is returned, or we could strike a middle ground by saying that an error is returned, and that it will typically be from among the set defined in http://openid.net/specs/openid-connect-core-1_0-14.html#AuthError, such as "login_required". I think I prefer the latter approach.

[Brian Campbell]

I think I also prefer the latter approach.

[Michael Jones]

Incorporated most of Brian Campbell's review comments and some from Torsten and others Fixed #878 - Generalized description of errors that can be returned when "id_token_hint" is used

→ <<cset b3b50fc961ff>>