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

Sascha Preibisch <> Wed, 26 May 2021 01:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E4A6E3A16F9 for <>; Tue, 25 May 2021 18:15:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7ndeZHqlyRmy for <>; Tue, 25 May 2021 18:15:54 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D30013A16F5 for <>; Tue, 25 May 2021 18:15:53 -0700 (PDT)
Received: by with SMTP id 131so40596721ljj.3 for <>; Tue, 25 May 2021 18:15:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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> <> <2022967056.41621972848831.JavaMail.root@shefa>
In-Reply-To: <2022967056.41621972848831.JavaMail.root@shefa>
From: Sascha Preibisch <>
Date: Tue, 25 May 2021 18:15:35 -0700
Message-ID: <>
To: "A. Rothman" <>
Cc: IETF oauth WG <>
Content-Type: multipart/alternative; boundary="000000000000279fc405c3316210"
Archived-At: <>
Subject: Re: [OAUTH-WG] Can a client send the Authorization Request?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 May 2021 01:15:59 -0000


I know POST won't be seen often, but the /authorize endpoint may still
accept POST as described here:

I hope this helps,

On Tue., May 25, 2021, 13:00 A. Rothman, <> 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):
> I have also
> made a video about this flow, maybe it matches what you are seeing on your
> web server:
> - 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 <> 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