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

"A. Rothman" <amichai2@amichais.net> Tue, 25 May 2021 14:59 UTC

Return-Path: <amichai2@amichais.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8709D3A0E63 for <oauth@ietfa.amsl.com>; Tue, 25 May 2021 07:59:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.391
X-Spam-Level: *
X-Spam-Status: No, score=1.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, MSGID_FROM_MTA_HEADER=0.001, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id g0I8PXlu82nP for <oauth@ietfa.amsl.com>; Tue, 25 May 2021 07:59:52 -0700 (PDT)
Received: from mail.freeutils.net (line134-103.adsl.actcom.co.il []) by ietfa.amsl.com (Postfix) with ESMTP id B606F3A0E62 for <oauth@ietf.org>; Tue, 25 May 2021 07:59:51 -0700 (PDT)
Message-ID: <952456782.01621954787444.JavaMail.root@shefa>
MIME-Version: 1.0
X-UserIsAuth: true
Received: from router.asus.com ([]) by mail.freeutils.net (JAMES SMTP Server 2.3.1) with SMTP ID 165 for <oauth@ietf.org>; Tue, 25 May 2021 17:59:47 +0300 (IDT)
To: oauth@ietf.org
From: "A. Rothman" <amichai2@amichais.net>
Date: Tue, 25 May 2021 17:59:47 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/gL25zG-X0kRBSg8LApF4DGiNODg>
Subject: [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: Tue, 25 May 2021 14:59:55 -0000


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 

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?