[Openid-specs-ab] Failed Authentication Attempts
George Fletcher
gffletch at aol.com
Wed Jun 6 14:52:13 UTC 2018
I'm good with adding an additional error response, I just like
"authentication_failed" much better than something that indicated part
of the authentication succeeded and part failed. Just being generic and
saying that authentication failed still allows the client to try a
different set of ACR values if it wants and it doesn't leak anything to
the attacker (e.g. the password you gave is good, just not the second
factor).
Thanks,
George
On 6/5/18 4:13 PM, Phil Hunt wrote:
> I think I see now…the last sentence isn’t clear on *how* the AS/OP
> treats the authen as failed.
>
> Phil
>
> Oracle Corporation, Identity Cloud Services Architect
> @independentid
> www.independentid.com <http://www.independentid.com>
> phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>
>
>> On Jun 5, 2018, at 1:09 PM, Torsten Lodderstedt
>> <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>> wrote:
>>
>>
>>
>>> Am 04.06.2018 um 18:42 schrieb Phil Hunt <phil.hunt at oracle.com
>>> <mailto:phil.hunt at oracle.com>>:
>>>
>>> I seem to recall Mike indicating that just because the OP could not
>>> meet the ACR requested, the RP/Client may still choose to accept the
>>> authentication at some reduced or alternate set of methods. IOW a
>>> fail to meet the ACR is not necessarily a fail.
>>
>>
>> That’s correct - if the acr claim was not requested as essential claim.
>>
>> For your convenience, here is the respective spec text again:
>>
>> "If the acr Claim is requested as an Essential Claim for the ID Token
>> with
>> a values parameter requesting specific Authentication Context Class
>> Reference values and the implementation supports the claims
>> parameter, the
>> Authorization Server MUST return an acr Claim Value that matches one
>> of the
>> requested values. The Authorization Server MAY ask the End-User to
>> re-authenticate with additional factors to meet this requirement. *If
>> this
>> is an Essential Claim and the requirement cannot be met, then the
>> Authorization Server MUST treat that outcome as a failed authentication
>> attempt*."
>>
>> I personally think the spec lacks an suitable error definition.
>>
>>>
>>> That said, no authentication at all should lead to an access_denied
>>> error at minimum.
>>>
>>> Phil
>>>
>>> Oracle Corporation, Identity Cloud Services Architect
>>> @independentid
>>> www.independentid.com <http://www.independentid.com/>
>>> phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>
>>>
>>>> On Jun 4, 2018, at 9:34 AM, Torsten Lodderstedt
>>>> <torsten at lodderstedt.net> wrote:
>>>>
>>>>
>>>>
>>>>> Am 01.06.2018 um 19:39 schrieb George Fletcher <gffletch at aol.com>:
>>>>>
>>>>> I think I'd prefer either 'access_denied' as defined by RFC 6749
>>>>> or an 'authentication_failed' error that is a little more generic
>>>>> than 'unable_to_meet_authentication_requirements' which I feel is
>>>>> leaking aspects of the authentication that shouldn't be exposed to
>>>>> the client.
>>>>
>>>> Take into account the RP asked for a certain ACR, which the OP was
>>>> unable to comply with.
>>>>>
>>>>> In the you case you provided Torsten, there isn't anything the RP
>>>>> can do as the user first needs to enable 2SV on their account at
>>>>> the OP.
>>>>
>>>> It can use another OP or implement the desired use case using local
>>>> means.
>>>>
>>>>>
>>>>> Thanks,
>>>>> George
>>>>>
>>>>> On 5/29/18 6:06 AM, Torsten Lodderstedt via Openid-specs-ab wrote:
>>>>>> That’s rather tricky. The OP must use this parameter to indicate
>>>>>> to the RP what acr policy it fulfilled in the respective
>>>>>> transaction. The value in acr is not necessarily the value the RP
>>>>>> asked for. But this holds only true if the acr claim was not
>>>>>> requested as essential claim. In this case, the OP must „MUST
>>>>>> treat that outcome as a failed authentication attempt.“ In my
>>>>>> interpretation, this requires the OP to send an error response to
>>>>>> the client, which only carries the error data.
>>>>>>
>>>>>>
>>>>>>> Am 28.05.2018 um 05:29 schrieb Phil Hunt <phil.hunt at oracle.com>
>>>>>>> :
>>>>>>>
>>>>>>> Isn’t this what the acr response param is for...
>>>>>>>
>>>>>>> acr
>>>>>>> OPTIONAL. Authentication Context Class Reference. String
>>>>>>> specifying an Authentication Context Class Reference value that
>>>>>>> identifies the Authentication Context Class that the
>>>>>>> authentication performed satisfied. The value "0" indicates the
>>>>>>> End-User authentication did not meet the requirements of ISO/IEC
>>>>>>> 29115 [ISO29115] level 1.
>>>>>>>
>>>>>>> Phil
>>>>>>>
>>>>>>> On May 27, 2018, at 9:00 AM, Torsten Lodderstedt via
>>>>>>> Openid-specs-ab
>>>>>>> <openid-specs-ab at lists.openid.net>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Hi Vladimir,
>>>>>>>>
>>>>>>>>
>>>>>>>>> Am 26.05.2018 um 23:42 schrieb Vladimir Dzhuvinov via
>>>>>>>>> Openid-specs-ab <openid-specs-ab at lists.openid.net>
>>>>>>>>> :
>>>>>>>>>
>>>>>>>>> If you're looking for a standard error code for "user failed
>>>>>>>>> to authenticate (with required ACR)", access_denied appears to
>>>>>>>>> be the closest and only choice. What the RP would make of that
>>>>>>>>> error code is another question :)
>>>>>>>>>
>>>>>>>>> http://openid.net/specs/openid-connect-core-1_0.html#AuthError
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In practice, many OPs won't send the browser back to the RP if
>>>>>>>>> the user failed to authenticate, i.e. the browser will remain
>>>>>>>>> at the login screen, with the user given the option for some
>>>>>>>>> sort of recovery and perhaps the option to cancel the request
>>>>>>>>> and return to the RP.
>>>>>>>>> As for login_required and interaction_required - my reading of
>>>>>>>>> the spec is that these are intended for error responses to
>>>>>>>>> prompt=none authentication requests and shouldn't be used to
>>>>>>>>> signal other conditions.
>>>>>>>>>
>>>>>>>>> http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest
>>>>>>>> That’s my problem. In my use case, the OP is unable to meet the
>>>>>>>> RP’s requirements either entirely or for the particular user
>>>>>>>> (e.g. no second factor available). I think stopping request
>>>>>>>> processing at the OP is not a good option. I would like to send
>>>>>>>> the user agent back to the RP along with enough information to
>>>>>>>> act upon. My current feeling is we need another, distinct error
>>>>>>>> code - something like authentication_failed
>>>>>>>> or unable_to_meet_authentication_requirements.
>>>>>>>>
>>>>>>>> best regards,
>>>>>>>> Torsten.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> none
>>>>>>>>>> The Authorization Server MUST NOT display any authentication
>>>>>>>>>> or consent user interface pages. An error is returned if an
>>>>>>>>>> End-User is not already authenticated or the Client does not
>>>>>>>>>> have pre-configured consent for the requested Claims or does
>>>>>>>>>> not fulfill other conditions for processing the request. The
>>>>>>>>>> error code will typically be login_required,
>>>>>>>>>> interaction_required, or another code defined in Section
>>>>>>>>>> 3.1.2.6. This can be used as a method to check for existing
>>>>>>>>>> authentication and/or consent.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Vladimir
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 25/05/18 18:41, Filip Skokan via Openid-specs-ab wrote:
>>>>>>>>>
>>>>>>>>>> Depending on the situation at the OP I believe this could be
>>>>>>>>>> any of (in
>>>>>>>>>> order of my preference) login_required, interaction_required,
>>>>>>>>>> access_denied
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>> *Filip Skokan*
>>>>>>>>>>
>>>>>>>>>> On Fri, May 25, 2018 at 4:13 PM, Torsten Lodderstedt via
>>>>>>>>>> Openid-specs-ab <
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> openid-specs-ab at lists.openid.net
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> I just came across the following text (again) in the OpenID
>>>>>>>>>>> Connect Core
>>>>>>>>>>> Spec:
>>>>>>>>>>>
>>>>>>>>>>> "If the acr Claim is requested as an Essential Claim for the
>>>>>>>>>>> ID Token with
>>>>>>>>>>> a values parameter requesting specific Authentication
>>>>>>>>>>> Context Class
>>>>>>>>>>> Reference values and the implementation supports the claims
>>>>>>>>>>> parameter, the
>>>>>>>>>>> Authorization Server MUST return an acr Claim Value that
>>>>>>>>>>> matches one of the
>>>>>>>>>>> requested values. The Authorization Server MAY ask the
>>>>>>>>>>> End-User to
>>>>>>>>>>> re-authenticate with additional factors to meet this
>>>>>>>>>>> requirement. If this
>>>>>>>>>>> is an Essential Claim and the requirement cannot be met,
>>>>>>>>>>> then the
>>>>>>>>>>> Authorization Server MUST treat that outcome as a failed
>>>>>>>>>>> authentication
>>>>>>>>>>> attempt.“
>>>>>>>>>>>
>>>>>>>>>>> What error code is the OP supposed to use to signal the failed
>>>>>>>>>>> authentication to the RP?
>>>>>>>>>>>
>>>>>>>>>>> best regards,
>>>>>>>>>>> Torsten.
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180606/99d34796/attachment.html>
More information about the Openid-specs-ab
mailing list