Re: [OAUTH-WG] How to enforce PKCE in authorization servers with a mix OAuth 2.0 and 2.1 clients?

Dima Postnikov <dima@postnikov.net> Sat, 08 October 2022 23:33 UTC

Return-Path: <dima.postnikov@gmail.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 4B6FCC14CE40 for <oauth@ietfa.amsl.com>; Sat, 8 Oct 2022 16:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.408
X-Spam-Level:
X-Spam-Status: No, score=-1.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=postnikov-net.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VWilPrrqdod for <oauth@ietfa.amsl.com>; Sat, 8 Oct 2022 16:33:29 -0700 (PDT)
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 189C5C14CE38 for <oauth@ietf.org>; Sat, 8 Oct 2022 16:33:29 -0700 (PDT)
Received: by mail-yb1-xb29.google.com with SMTP id 207so9526629ybn.1 for <oauth@ietf.org>; Sat, 08 Oct 2022 16:33:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=postnikov-net.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MhJK5EA6zeRvLQk3Xafy0ixfLlCQKD7uCYDbejqgeXs=; b=eXEe2eturArIgm0XI3Pwo43bU/vrXS8pXAmMGGz2h3ktrj9HiIh4o/aptAmGv9HVVO hkSJUetoVIdHvjiHmbtHBB1I/cnbRL6pni17rHeyeQjA+wpVNN41eAWLpMTPQmGn900Y oU2iKUMDt+9G3ZYOGpWCyCaSZBvtfy1UgaRTHy0f08plo1ZT/Sl9eVunbTDkwvxIO3QI LNY3eznd/Phs8bSycxIGicmbF33ZiytiY2zZ07NllhwG6BSifbut3XWGIekETmKav1vo SP22mF6t5vC9iF/yUFSxoKwibTMxUaH0GQlpMacZvvf6D3wwdoPbEgyHxkPL3mCmoBkt 9TlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MhJK5EA6zeRvLQk3Xafy0ixfLlCQKD7uCYDbejqgeXs=; b=TAiGTGOxrsF2FBqhqWXV9fz1SqzBZCp62nkiGuBlny3dqiXcnFTzMnuf/S8ZoRh2OH ocIs5DUfREudmSVv7E1476vSc00m7fgJk7tMdGKP+si5pE7YlnFIDOmYtCHphM0azHHP Qf/jG3DApk/RwpJEBQ2T98agehGa8zggETYXihox8vHCjXB0e3hkAK5lcL/iopVSsVcW ttVexHwLJVbFUGRkM58VtEFVPzV5p096tO5RLPZ+YamzYOYktxe12EdadIqImbPEwbkU YSDXqe+lDwEZh+Dud/SU8LYxIOgSQOt5JPRF/ps4jVZxdFvhtsUOLUxXsrnPBgEv2qfc LQlQ==
X-Gm-Message-State: ACrzQf0mHgOAL2gcXDXUBWooUcrTpMCWu8P6nNNTOIsxg3aTEDxeUKLX 2DHK7ywhJXRn+l9skColqF8QxT9RIGucHUVhvvo=
X-Google-Smtp-Source: AMsMyM7PeTbNNVCEhAuV2q+gdVraY/VQ41JOVNp576IJHbYPdxqU2KVnmCyDjf5CcGdCayexDVne6lamfDcujkKzxKM=
X-Received: by 2002:a05:6902:1245:b0:6be:135e:8dfb with SMTP id t5-20020a056902124500b006be135e8dfbmr11032577ybu.626.1665272007908; Sat, 08 Oct 2022 16:33:27 -0700 (PDT)
MIME-Version: 1.0
References: <ba1a5680-616c-bfe1-46b7-899acbb180bf@connect2id.com> <CAEMK1uZzsx6a-EHuBuPMomTLdDE798jcBaWNTABzERnLVuM6Qw@mail.gmail.com> <227a5b14-5017-2f55-737a-74b94165b1c0@connect2id.com>
In-Reply-To: <227a5b14-5017-2f55-737a-74b94165b1c0@connect2id.com>
From: Dima Postnikov <dima@postnikov.net>
Date: Sun, 09 Oct 2022 10:33:17 +1100
Message-ID: <CAEMK1uZXPHJueuiOK3m6wBFsTafoe5UQ2mr=FxK4kD2jMVdQnw@mail.gmail.com>
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
Cc: oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007c62ca05ea8e5ad8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/BFCkm9KSbbM86PxGNI-XIPZOAPs>
Subject: Re: [OAUTH-WG] How to enforce PKCE in authorization servers with a mix OAuth 2.0 and 2.1 clients?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 08 Oct 2022 23:33:33 -0000

Hi Vladimir.

Client registration parameter sounds like a good idea to me.

In terms of which document this goes to.... I wonder if PKCE RFC7636 could
be updated to add this. This way ecosystems using PKCE in OAuth 2.0 could
benefit from this too.

Thanks

Dima


On Sat, Oct 8, 2022 at 9:27 PM Vladimir Dzhuvinov <vladimir@connect2id.com>
wrote:

> Thanks for chiming in Dima.
>
> Do you reckon it's a good idea to define a code_challenge_method client
> reg parameter in the OAuth 2.1 spec?
>
> To enable 2.0 -> 2.1 transitions and also give people a concrete and
> standard compliant way to implement the "REQUIRED or RECOMMENDED" in the
> OAuth 2.1 spec for code_challenge.
>
> Another spec that deals with PKCE is the OAuth BCP, but to me that's not a
> optimal place to define a new parameter.
>
>
> Vladimir Dzhuvinov
>
>
> On 08/10/2022 04:31, Dima Postnikov wrote:
>
> Hi Vladimir,
>
> Similar issue exists in CDR (Australian Open Banking). PAR and PKCE was
> added as mandatory to FAPI 1 Advanced profile.
>
> There was a transition period when AS had to support both (potentially).
>
> Also if the same AS is used outside of CDR, this dual support would
> continue for some implementations.
>
> I don't think this was solved, so your client registration parameter
> makes sense.
>
>
>
> On Wed, Oct 5, 2022 at 5:43 PM Vladimir Dzhuvinov <vladimir@connect2id.com>
> wrote:
>
>> Has anyone faced the issue how an AS can handle a mix of OAuth 2.0 and
>> 2.1 clients regarding PKCE enforcement?
>>
>> The new OAuth 2.1 spec makes PKCE required, which is a good security
>> measure and fine for an AS where all clients are ready to comply with
>> the upgrade. In practice however, it's common for AS deployments to have
>> a mix of legacy 2.0 and 2.1 clients, and at present OAuth doesn't have a
>> standard client registration parameter, e.g. code_challenge_method, to
>> lock a client into using PKCE.
>>
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-02#section-4.1.1
>>
>> RFC 8414 defined the code_challenge_methods_supported metadata for
>> servers. It would be useful if deployments had a corresponding parameter
>> for the clients.
>>
>> https://www.rfc-editor.org/rfc/rfc8414
>>
>> ~ Vladimir
>>
>> --
>> Vladimir Dzhuvinov
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>