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

Torsten Lodderstedt <> Tue, 25 May 2021 15:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 076CD3A1058 for <>; Tue, 25 May 2021 08:25:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Status: No, score=-2.087 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 oJj_RvSPMsL8 for <>; Tue, 25 May 2021 08:25:25 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 21B133A1053 for <>; Tue, 25 May 2021 08:25:24 -0700 (PDT)
Received: by with SMTP id f6-20020a1c1f060000b0290175ca89f698so13704305wmf.5 for <>; Tue, 25 May 2021 08:25:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fPKG0es0vbSQ5XIBVdMIJgcpE3jJaW35d6mJmx82du0=; b=TBbGY+wZWV2yEQQawZiLllBkllWbBM3XsudsvAMwRQ92zWnOOF//JUtxRUTc87p4/M SyIs8MYdUMsd8v5UdTbmGhlbsH54spjPsV6Z2vw6RKjJ7CJ4572h6JBuViaGgi6poRUz mzwJkBexZpnaYm0REM2K1QlQd6244vb71O2ZesQfLvsexsaSk2U0787Ds8XQT2U3IGhK wgUoQkiLWDjhJzpf0AvFGv8EWSyJbQctE0WhjIwKpY8h1uNKazvoVb2l9B0YgSiMVnjR oIjaENP07bUZ/ZYQw1OlDDeSRmV/9sPi3X0cER7uiVqzA5dEya9pAcSED1D1ANXpuvHh mxNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fPKG0es0vbSQ5XIBVdMIJgcpE3jJaW35d6mJmx82du0=; b=Z1ePyq/+RfUhI2xCkk8Kam6Fx/CKwcmhnuoM7WiLTL7+tLTxSbkNTCoR6pLCWJeb+6 EIXIaklMtdfoU4qpmsOkcq9t7HfBcy3fhM1GbyeFisYK+v1+6QUHZ+jSuJSu2Uhd1EnA B6NZ4uJOuvE48zATeG3EngsrBnEd/LpOQoTpYGq8MRUyDA5/9EtbZw1aOpWjiFiorwqR h3NRdujSWyFTVkOrPbYrGrUOqdSO67KStyxEP1RWoZHYWwbdseD4loaZYkKT6qT0x4ty Nyjf6yUQnzzBMZAw/2G6bGV1DqzRuqVskv1mwkAF72Gl79c2uNfKD2VNTUY0J87HHauG Ig5w==
X-Gm-Message-State: AOAM532eP+uEY86Oq5ew3MNMMtrLxDGf69uqrcvulbjQpCkPPqmWnANp 1vrzDY71/hYblcKPGUgAr+C9nw==
X-Google-Smtp-Source: ABdhPJzVg0JoWzAtbWfOQVM9HWUcnvK1QTqCMeFTccGRwH28svKG1ef7K0/eJLf3zeL5dvORqUGWyg==
X-Received: by 2002:a05:600c:35d3:: with SMTP id r19mr4383946wmq.3.1621956321773; Tue, 25 May 2021 08:25:21 -0700 (PDT)
Received: from ( []) by with ESMTPSA id e22sm11169725wme.48.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 May 2021 08:25:21 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Torsten Lodderstedt <>
In-Reply-To: <952456782.01621954787444.JavaMail.root@shefa>
Date: Tue, 25 May 2021 17:25:20 +0200
Cc: oauth <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <952456782.01621954787444.JavaMail.root@shefa>
To: "A. Rothman" <>
X-Mailer: Apple Mail (2.3654.
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: Tue, 25 May 2021 15:25:31 -0000


> Am 25.05.2021 um 16:59 schrieb A. Rothman <>et>:
> 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?

I don’t think so. 

> 3. Is it any less secure? (even if not strictly compliant with the RFC's flow, it may still be secure...)

Difficult to access without further details. Beside this, I see the service provider as being responsible to ensuring it is 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?

I kind of understand the rationale. Sending the authorisation request to the AS first (using mTLS) allows the AS to check the client’s identity and permissions before the user interaction starts. With a standard redirect (without signed request objects), the AS never knows whether request really comes from the legit client. This is determined once the code is exchanged at the token endpoint (rather late in the process). 

Fo this and other reasons, the OAuth WG has specified the Pushed Authorization Requests ( extension that works similarly. We indeed have done a security analysis of this draft. 

BTW: the communication between user agent and authorisation server is still not protected with mTLS in the solution you described ;-).

best regards,

> Thanks,
> Amichai
> _______________________________________________
> OAuth mailing list