[Openid-specs-ab] Failed Authentication Attempts

Thu Jun 7 14:34:46 UTC 2018

Good discussion. Torsten, could you put this in the issue tracker?

On Thu, Jun 7, 2018 at 12:02 AM George Fletcher via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> 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
> phil.hunt at oracle.com
>
> On Jun 5, 2018, at 1:09 PM, Torsten Lodderstedt <torsten at lodderstedt.net>
> wrote:
>
>
>
> Am 04.06.2018 um 18:42 schrieb Phil Hunt <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
> phil.hunt at oracle.com
>
> On Jun 4, 2018, at 9:34 AM, Torsten Lodderstedt <torsten at lodderstedt.net>
> <torsten at lodderstedt.net> wrote:
>
>
>
> Am 01.06.2018 um 19:39 schrieb George Fletcher <gffletch at aol.com>
> <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>
> <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> <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> <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
>
>
>
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180607/93bc3114/attachment.html>