Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

Warren Parad <wparad@rhosys.ch> Wed, 13 October 2021 17:27 UTC

Return-Path: <wparad@rhosys.ch>
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 9C8C13A0773 for <oauth@ietfa.amsl.com>; Wed, 13 Oct 2021 10:27:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch
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 QPe5ISxnYKTl for <oauth@ietfa.amsl.com>; Wed, 13 Oct 2021 10:27:16 -0700 (PDT)
Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 CECD03A0772 for <oauth@ietf.org>; Wed, 13 Oct 2021 10:27:15 -0700 (PDT)
Received: by mail-yb1-xb2a.google.com with SMTP id h2so8110282ybi.13 for <oauth@ietf.org>; Wed, 13 Oct 2021 10:27:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jc4vyoiMtOZNSocx+ZOyIorM6U7cPKgUhESmNBL3GDk=; b=PiynGE/MmPnZEG/d+ngz5fFc78WdT5cVnMqgIuytpECYxKdcZ8UIrf4XgX9sQozUyf dTk3SAewueNSIKOYOulDSNXBzWYfSp7hCj5b4wCc9v/AjfxiayChrD13KinVFNTFd7dS RMN3w/Z569xFfOueiP9HRXJrA/rAjMttFQA+1s7FZxzJhzf33DvXSSmrslK7QWWAQBib ghnn8iwqwikUnkHYXElTtRVbtq2wn/2mLuh2Ng0VlnMeU8XBE0sODVGi/7xxeHJ5s8SP d2xezPv3/2n6sRoM445pUBrrnhEvetmgThnoMPtzVkSuZ0d9LVqjPtlCbRU3dPmyrnHw q6IQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jc4vyoiMtOZNSocx+ZOyIorM6U7cPKgUhESmNBL3GDk=; b=vYpeHm4zr11mNaDWmJzt7ggZa0m7Qk90CxT3KIWnuQf/uaLBldTnRSKO7dKkcwWUQH wtfpGIzstWxJ5e7ghPn6c2u+noi7dARwOz0P5pwsEBkMrFIUQUw+EXmdsfzq1Ut++Imi iYE5qwDeB5Zp+igOQGPwQYHqUtTRC5Rs6KUXpAglXFtpVD4Ve0uIh6AhBJR0AfhSj0R6 aT8DzXnitvo52n+AQ75Dgg3H6QnHsFM8bG8AHBhkXMzUouvY7+yjv7qvJgeDjeM5UwTV tPzUG5+oJWyjGAXjJG5F8RxYi6VJfBEaWUzkvi6MKe+/dfMvbcqO7bZ+Wx+EI1eG7ze5 tEgQ==
X-Gm-Message-State: AOAM533xf6TE4jieoHYueUtdzBYDr4Tr2915KVaZwWeVOC5XfC6yOsiR m8xsJ2wRGlr0k70+t6xVXBh43dXV24cR6GckNWQ7YCCCsesu5jk=
X-Google-Smtp-Source: ABdhPJwkZu9MwKke4icN5C/E4ncXenJAdmJvr61TOX8B31uMm8ktbwXbJjrwCtrVHau35ES0Zz4z0qRlgyFuoCv6S9U=
X-Received: by 2002:a25:5f46:: with SMTP id h6mr681843ybm.209.1634146034639; Wed, 13 Oct 2021 10:27:14 -0700 (PDT)
MIME-Version: 1.0
References: <SA2PR00MB100244DAAD267EBD2FF51678F5B79@SA2PR00MB1002.namprd00.prod.outlook.com>
In-Reply-To: <SA2PR00MB100244DAAD267EBD2FF51678F5B79@SA2PR00MB1002.namprd00.prod.outlook.com>
From: Warren Parad <wparad@rhosys.ch>
Date: Wed, 13 Oct 2021 19:27:03 +0200
Message-ID: <CAJot-L1HNvud7-ehODK7Bouv5-KotMy8EtEgLCyCzOXoSZCVCg@mail.gmail.com>
To: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e7f6ac05ce3f4581"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/2nO5N_kCUEPwZXFV6aN9rFnvf9k>
Subject: Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1
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: Wed, 13 Oct 2021 17:27:21 -0000

Isn't it better for it to be worded as we want it to be, with the
implication being that of course it might be difficult to do that, but that
AS devs will think long and hard about sometimes not denying the request?
Even with MUST, some AS will still allow reuse of auth codes. Isn't that
better than flat out saying: *sure, there's a valid reason*

In other words, how do we think about RFCs? Do they exist to be followed to
the letter or not at all? Or do they exist to stipulate this is the way,
but acknowledge that not everyone will build a solution that holds them as
law.

Let's look at *SHOULD*

> This word, or the adjective "RECOMMENDED", mean that there may exist valid
> reasons in particular circumstances to ignore a particular item, but the
> full implications must be understood and carefully weighed before choosing
> a different course.


I think *recommended* here is not sufficient nor are there valid reasons.
"It's too hard" isn't really a valid reason. Isn't it better in this case
for an AS to not be compliant with the RFC, than it is to relax this to
SHOULD and have lots of AS thinking reusing auth codes is a viable
solution, "because they are a special snowflake where SHOULD should apply".

Are we setting the standard or instead attempting to sustain a number of
"AS that are in compliance with the RFC"?


Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Wed, Oct 13, 2021 at 7:17 PM Mike Jones <Michael.Jones=
40microsoft.com@dmarc.ietf.org> wrote:

> During today’s call, it was asked whether we should drop the OAuth 2.0
> language that:
>
>          The client MUST NOT use the authorization code
>
>          more than once.  If an authorization code is used more than
>
>          once, the authorization server MUST deny the request and SHOULD
>
>          revoke (when possible) all tokens previously issued based on
>
>          that authorization code.”
>
>
>
> The rationale given was that enforcing one-time use is impractical in
> distributed authorization server deployments.
>
>
>
> Thinking about this some more, at most, we should relax this to:
>
>          The client MUST NOT use the authorization code
>
>          more than once.  If an authorization code is used more than
>
>          once, the authorization server SHOULD deny the request and SHOULD
>
>          revoke (when possible) all tokens previously issued based on
>
>          that authorization code.”
>
>
>
> In short, it should remain illegal for the client to try to reuse the
> authorization code.  We can relax the MUST to SHOULD in the server
> requirements in recognition of the difficulty of enforcing the MUST.
>
>
>
> Code reuse is part of some attack scenarios.  We must not sanction it.
>
>
>
>                                                           -- Mike
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>