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

[Vladimir Dzhuvinov]

Hi Dima,








From the perspective of an OAuth 2.1 deployment it would be S256.



Vladimir Dzhuvinov

On 09/10/2022 02:33, Dima Postnikov wrote:

A published RFC cannot be extended to specify new things, only have errata added it. The OAuth 2.1 spec is still a draft in the works. What do you think is a suitable default value for a code_challenge_method client reg parameter? From the perspective of an OAuth 2.0 deployment it could be none (i.e. no PKCE) or S256, in the latter case a client will need to explicitly opt out of it, but how exactly?

Hi Vladimir.

Client registration parameter sounds like a good idea to me.



Thanks

Dima




    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:

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. On Sat, Oct 8, 2022 at 9:27 PM Vladimir Dzhuvinov <vladi...@connect2id.com> 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
    <vladi...@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



        _______________________________________________
        OAuth mailing list
        OAuth@ietf.org
        https://www.ietf.org/mailman/listinfo/oauth

-- Vladimir Dzhuvinov

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth