Re: [OAUTH-WG] Can a client send the Authorization Request?

Sascha Preibisch <saschapreibisch@gmail.com> Wed, 26 May 2021 01:15 UTC

Return-Path: <saschapreibisch@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 E4A6E3A16F9 for <oauth@ietfa.amsl.com>; Tue, 25 May 2021 18:15:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7ndeZHqlyRmy for <oauth@ietfa.amsl.com>; Tue, 25 May 2021 18:15:54 -0700 (PDT)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 D30013A16F5 for <oauth@ietf.org>; Tue, 25 May 2021 18:15:53 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id 131so40596721ljj.3 for <oauth@ietf.org>; Tue, 25 May 2021 18:15:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lV2Brqcdvk43dxNoW2RQ1H8lZ8fkRbA/PTFpeHcoDBc=; b=Hxwb1byZyK23V20ihyyr9uQdhjyRmRDILAimf9QQblGd97Bj6y5zi1q15SMa8/4rJX eTYnZgi+2icIVR4K045Vs86Y6Y0+SnZxQdJGVsgF5S9ksgOw8yS1vMPkITggTnizZV+R O4jycgSN/pr9N2OOZ6dg1bjnqnoQ7G0SfiIyo4Ukjsh0JLQwCGjw3U4RtLzXTKmIAKNB bGoGxW1fE/cNAA+I8FlimgBPjVKYjn7/K93lblviEUjhjwWVXcLF5xqPguerZq/XhJmU ZMt3A6+ENqbf+wM7zCqUmUqtUE4YFoe1l0OhNFvZb4DFwI4FA8rCteiauV5lN4Quq1oK o27w==
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=lV2Brqcdvk43dxNoW2RQ1H8lZ8fkRbA/PTFpeHcoDBc=; b=ajeYzbDg6rAbJiU27sAV5FS7hOsCK8HDhwFFa+aeEKWy6JX2oaSQ7gbF2VTuM4WdnL oamlq1sVeZOaCYSVHidBkc2wgdmlI0vfyhDqED5WuPa8Sr6xAbUD59SZDIHqy9j6NAeJ Nuo+KuDHqDz6L8baW9oxZ6S5kcMrC64ps3tEmyuPvBif4sDPjsDqM3O7PPRLDGEg/0Bq UlqhHPi7t/5aLf09Uv3fvOuBJGd9ZdRdwEcTfVV2Ns2Tn24RcsXI9erFOMfvxBiE3UJc 6am3I1+R85yVV9WL2//32USaXxaVVFIoAPlNBIXbSvr7rqXImNHrrn7ZWnDxdNVktUje nVHg==
X-Gm-Message-State: AOAM5319UaQ6NXijdOqOkkiKFrZbOvf21fm/FD+s6tLRkUSHLl/F7OUb 3Yt5qU/Ihb06Sdm8t/KMtms8kJFimh3Vb4GMOZo=
X-Google-Smtp-Source: ABdhPJwaSnupX313yExbCxXGqw+BctOWr7aw2hZfzqkabHeNHE4FYEso3TTHvPBnw5TFu71WA2WohnAosVhczak5/Ps=
X-Received: by 2002:a2e:9806:: with SMTP id a6mr289771ljj.214.1621991751129; Tue, 25 May 2021 18:15:51 -0700 (PDT)
MIME-Version: 1.0
References: <952456782.01621954787444.JavaMail.root@shefa> <CAP=vD9sq72MKuw37voGE-0FAHpDXS-QsaRDHK04d3jFuNunyHA@mail.gmail.com> <2022967056.41621972848831.JavaMail.root@shefa>
In-Reply-To: <2022967056.41621972848831.JavaMail.root@shefa>
From: Sascha Preibisch <saschapreibisch@gmail.com>
Date: Tue, 25 May 2021 18:15:35 -0700
Message-ID: <CAP=vD9uEAQ8W19Gg61mUXdZHyZimibMPx9q=DKWincpoG9NVUQ@mail.gmail.com>
To: "A. Rothman" <amichai2@amichais.net>
Cc: IETF oauth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000279fc405c3316210"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/uJmNi-v6-tJDbA1AqojtN9MgEqU>
Subject: Re: [OAUTH-WG] Can a client send the Authorization Request?
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, 26 May 2021 01:15:59 -0000

Amichai,

I know POST won't be seen often, but the /authorize endpoint may still
accept POST as described here:
https://tools.ietf.org/html/rfc6749#section-3.1

I hope this helps,
Sascha


On Tue., May 25, 2021, 13:00 A. Rothman, <amichai2@amichais.net> wrote:

> Hi Sacha,
>
> Thanks for the links and video!
>
> However I don't think this is what they're doing. There's no par endpoint,
> no JSON response (just a redirect with a Location header, that instead of
> following, the client is supposed to pass through to the user agent), etc.
> It seems more like a regular OAUTH2 flow, just with the initial request
> coming out of the client instead of the user agent, without any of the
> specifics of the par mentioned in the video.
>
> btw, where does RFC 6749 say the authorization request can be sent by the
> client? In the quote I made below from 4.1, as well as e.g. 4.2.1, it seems
> pretty explicit that it's the user agent that makes the actual HTTP request
> (Authorization Request with all its params etc), after being redirected to
> it from the client, no? I don't see much wiggle room there to allow for the
> client to be sending it itself...
>
> Amichai
> On 5/25/21 6:28 PM, Sascha Preibisch wrote:
>
> Hello Amichai!
>
> There could be several reasons why you see that behaviour in your web
> browser. For example:
>
> - This RFC suggests sending a request to the authorization server, get a
> session specific URL back which can be forwarded to the authorization
> server via the browser. This is OAuth PAR (Pushed Authorization Request):
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par. I have also
> made a video about this flow, maybe it matches what you are seeing on your
> web server: https://www.youtube.com/watch?v=fE11HJRCL-k
>
> - In addition RFC 6749 also allows a client to POST to the authorization
> endpoint
>
> I hope this helps,
> Sascha
>
> On Tue, 25 May 2021 at 08:00, A. Rothman <amichai2@amichais.net> wrote:
>
>> Hi,
>>
>> In RFC 6749 section 4.1, the Authorization Code Grant flow starts with:
>>
>> (A)  The client initiates the flow by directing the resource owner's
>>          user-agent to the authorization endpoint.  The client includes
>>          its client identifier, requested scope, local state, and a
>>          redirection URI to which the authorization server will send the
>>          user-agent back once access is granted (or denied).
>>
>> (B)  The authorization server authenticates the resource owner (via
>>          the user-agent) and establishes whether the resource owner
>>          grants or denies the client's access request.
>>
>>
>>  From this, and most explanation I've seen, I understand that the client
>> (e.g. my web server) is supposed to prepare the Authorization Request
>> URL but instead of sending it to the Authorization Server, it redirects
>> the user agent which is the one actually making the HTTP request. It
>> then goes back and forth with the Authorization Server (with HTML and
>> posting forms and whatnot), and eventually receives the Authorization
>> Response which redirects the user agent back to the client's callback
>> URL with the included code parameter. So as far as the Authorization
>> Request/Response flow goes, there is no direct communications between
>> the client and Authorization Server up to this point (before the token
>> exchange).
>>
>> 1. Basically correct so far?
>>
>> Now, I've encountered a provider that works slightly differently (but
>> still with the Authorization Code Grant scheme): the client (my web
>> server) is supposed to send the Authorization Request directly to the
>> Authorization Server, then receive some opaque URL, and redirect the
>> user agent to there to continue the process. I suppose this URL is
>> equivalent to one from the middle of the 'back and forth' in the
>> previous scenario. The rest of the flow continues the same. So
>> basically, the initial redirect response and HTTP request are reversed -
>> instead of first redirect and then request (from user agent), there is
>> first the request (from client)  and then redirect.
>>
>> So the questions are:
>>
>> 2. Is this compliant with the RFC?
>>
>> 3. Is it any less secure? (even if not strictly compliant with the RFC's
>> flow, it may still be secure...)
>>
>> 4. If it is less secure, what are the possible vulnerabilities or
>> attacks made possible here that are mitigated in the original flow?
>>
>> 5. They claim the change is made because they insist on using MTLS on
>> all Authentication Server endpoints, including the Authorization
>> Endpoint. Does this make sense? Does it add security, or is the OAUTH2
>> flow just as secure without MTLS on the Authorization Endpoint?
>>
>> Thanks,
>>
>> Amichai
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>