On 2019-02-22 10:29 a.m., George Fletcher wrote: > I believe Torsten proposed an "authentication_failed" error response > in a different context. Possibly we could use that? > > Alternatively, OpenID Connect defines a 'login_required' error that > could work in this context as well. It doesn't fit the semantic as > defined in the OIDC spec, but as an error would work. > > If we need to use an existing OAuth2 error code, then I'd recommend > 'invalid_request' in that the request is invalid because there are too > many of them which is indicated by the 429 HTTP error code.
What benefit would a specific request body serve? Should a client behave differently if they got a 429 from an intermediate oauth2-unaware proxy vs an oauth2 server that emits this body? > > On 2/22/19 9:53 AM, Aaron Parecki wrote: >> HTTP 429 sounds fine for the HTTP response code, but what about the >> OAuth error code string? "invalid_grant" seems closest but doesn't >> sound right because if the app tries the same request again later it >> would be valid. >> >> >> >> On Fri, Feb 22, 2019 at 6:02 AM George Fletcher <gffle...@aol.com >> <mailto:gffle...@aol.com>> wrote: >> >> +1 for using 429 >> >> >> On 2/22/19 2:09 AM, David Waite wrote: >>> I don’t believe that any of the currently registered error codes >>> are appropriate for indicating that the password request is >>> invalid, let alone a more specific behavior like rate limiting. >>> >>> It is also my opinion that 400 Bad Request shouldn’t be used for >>> known transient errors, but rather for malformed requests - the >>> request could very well be correct (and have the correct >>> password), but it is being rejected due to temporal limits >>> placed on the client or network address/domain. >>> >>> So I would propose a different statuses such 401 to indicate the >>> username/password were invalid, and either 429 (Too many >>> requests) or 403 (Forbidden) when rate limited or denied due to >>> too many attempts. Thats not to say that the body of the >>> response can’t be an OAuth-format JSON error, possibly with a >>> standardized code - but again I don’t think the currently >>> registered codes would be appropriate for conveying that. >>> >>> That said, I don’t know what interest there would be in >>> standardizing such codes, considering the existing >>> recommendations against using this grant type. >>> >>> -DW >>> >>>> On Feb 21, 2019, at 10:57 PM, Aaron Parecki <aa...@parecki.com >>>> <mailto:aa...@parecki.com>> wrote: >>>> >>>> The OAuth password grant section mentions taking appropriate >>>> measures to rate limit password requests at the token endpoint. >>>> However the error responses section ( >>>> https://tools.ietf.org/html/rfc6749#section-5.2) doesn't >>>> mention an error code to use if the request is being rate >>>> limited.. What's the recommended practice here? Thanks! >>>> >>>> Aaron >>>> >>>> -- >>>> ---- >>>> Aaron Parecki >>>> aaronparecki.com <http://aaronparecki.com/> >>>> @aaronpk <http://twitter.com/aaronpk> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >> >> -- >> ---- >> Aaron Parecki >> aaronparecki.com <http://aaronparecki.com> >> @aaronpk <http://twitter.com/aaronpk> >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
