IETF Logo Mail Archive

Re: [OAUTH-WG] Correct error code for rate limiting?

Aaron Parecki <aaron@parecki.com> Fri, 22 February 2019 14:53 UTC

Return-Path: <aaron@parecki.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88ABC1200D7 for <oauth@ietfa.amsl.com>; Fri, 22 Feb 2019 06:53:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tapvoTSI2o9n for <oauth@ietfa.amsl.com>; Fri, 22 Feb 2019 06:53:20 -0800 (PST)
Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6799130DBE for <oauth@ietf.org>; Fri, 22 Feb 2019 06:53:19 -0800 (PST)
Received: by mail-it1-x133.google.com with SMTP id e24so3287852itl.1 for <oauth@ietf.org>; Fri, 22 Feb 2019 06:53:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zbJQFzibWcjjFHIWTK8XGj44bKGAbG49iabZ7Xq0AtU=; b=wvmG1eMUwxCJOnZsBfL2btYV6b8SHJ7MCCqi6SonGTfRGjymqIkQhzjVGKOCKUYTY1 l3KOD5psZJI8zR5u7IuLl4cXf5CfwbDJjr8EiRa4AOUmI/rR34FK4BDua1Q4JbOMTR9V litkDtSvgymXY/mE0Uujqw/dSkknk/tTkmuuAG58oOTKagqKe5vfOplI9YznzIuPucFl GAkzV5RyNGVYik9ekT0YU0orR5imprjvkmwpEgy33VzGmeNugMB1+XvO5iOs3D+fKrq/ Bm4x38ijLkLk/iLAthX2dCqszpeEw5Jq5snQp06uT1om0Nos769z7Pys/D1k6N3Sa600 X5Kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zbJQFzibWcjjFHIWTK8XGj44bKGAbG49iabZ7Xq0AtU=; b=ZFaNx2H7VOe/bygIToYiSZ5cRltWNlGYaKPyLJx4kHRJ3PKbxkK0ubbtv2goZGd8/g GuH8SMhJiRMgYaREsRUiXVDrPFjnv7x4TX8iUa2VkY+g/FGxBKLXNfsXyRvctRiGubsQ qaN7uozKd/+WQiPsQuUaTxwZg2P2SoKUSX/2dZpwBiRg5QH0wli+Xgy2BItmXqFKn2g8 t6/Be88wbDnzh93t3PBvNV6cwj1NJGgq+jACFP/7xl4q+Ug3BVDB/8pEgE6+qW2elmUF 1Q2EPpiY3/PZiZ2RymdpUViPuOP8NKHhdJ8SC5LlqkP23h83IEUiUNOFvfaSHXrDU6j3 Mrmw==
X-Gm-Message-State: AHQUAuaptlN2/vWOn/a33T+ccQsp5ym4CZz5HNYjeTDNS7JN1sIPl4EN oXo6cFCfnT7E01cQEBRI7VCYb4jRCfA=
X-Google-Smtp-Source: AHgI3IaW9fSYreRnYtMIyHlH2Evecm8O4EwkDGoBm8wbwhFy/aQC84xQzIpcF4v7xFu3Y8jcjZlykg==
X-Received: by 2002:a05:660c:d4:: with SMTP id q20mr2561137itk.21.1550847198537; Fri, 22 Feb 2019 06:53:18 -0800 (PST)
Received: from mail-it1-f173.google.com (mail-it1-f173.google.com. [209.85.166.173]) by smtp.gmail.com with ESMTPSA id u24sm577304ior.59.2019.02.22.06.53.16 for <oauth@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Feb 2019 06:53:16 -0800 (PST)
Received: by mail-it1-f173.google.com with SMTP id x131so3269656itc.3 for <oauth@ietf.org>; Fri, 22 Feb 2019 06:53:16 -0800 (PST)
X-Received: by 2002:a02:308:: with SMTP id y8mr2563189jad.142.1550847196645; Fri, 22 Feb 2019 06:53:16 -0800 (PST)
MIME-Version: 1.0
References: <CAGBSGjrrVbZhcnA8dNMp7xJnceGj8GzFJ-PeqQ6yFrOpgYjG5Q@mail.gmail.com> <9D2FC54D-176A-465A-8908-6D680763079C@alkaline-solutions.com> <3367c77f-e635-3443-1833-b23018e6795e@aol.com>
In-Reply-To: <3367c77f-e635-3443-1833-b23018e6795e@aol.com>
From: Aaron Parecki <aaron@parecki.com>
Date: Fri, 22 Feb 2019 06:53:05 -0800
X-Gmail-Original-Message-ID: <CAGBSGjqLf4cMhJ8=EVTy1i7DX7MO92ioW5vR75sfFSEKRKjSuA@mail.gmail.com>
Message-ID: <CAGBSGjqLf4cMhJ8=EVTy1i7DX7MO92ioW5vR75sfFSEKRKjSuA@mail.gmail.com>
To: George Fletcher <gffletch@aol.com>
Cc: David Waite <david@alkaline-solutions.com>, OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000041d02d05827cc050"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/I7rLsN0srvA553MyjiKa0Op6XUw>
Subject: Re: [OAUTH-WG] Correct error code for rate limiting?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Feb 2019 14:53:24 -0000

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 <gffletch@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 <aaron@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
> @aaronpk <http://twitter.com/aaronpk>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> --
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

v2.23.0 | Report a Bug | By Email