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

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

Return-Path: <amichai2@amichais.net>
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 B82593A1BAA for <oauth@ietfa.amsl.com>; Tue, 25 May 2021 13:00:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.393
X-Spam-Level: *
X-Spam-Status: No, score=1.393 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 yEiPlyHfE3IO for <oauth@ietfa.amsl.com>; Tue, 25 May 2021 13:00:52 -0700 (PDT)
Received: from mail.freeutils.net (line134-103.adsl.actcom.co.il [192.115.134.103]) by ietfa.amsl.com (Postfix) with ESMTP id 489A53A1BA7 for <oauth@ietf.org>; Tue, 25 May 2021 13:00:51 -0700 (PDT)
Message-ID: <2022967056.41621972848831.JavaMail.root@shefa>
MIME-Version: 1.0
X-UserIsAuth: true
Received: from router.asus.com ([192.168.80.1]) by mail.freeutils.net (JAMES SMTP Server 2.3.1) with SMTP ID 237; Tue, 25 May 2021 23:00:48 +0300 (IDT)
To: Sascha Preibisch <saschapreibisch@gmail.com>
Cc: IETF oauth WG <oauth@ietf.org>
References: <952456782.01621954787444.JavaMail.root@shefa> <CAP=vD9sq72MKuw37voGE-0FAHpDXS-QsaRDHK04d3jFuNunyHA@mail.gmail.com>
From: "A. Rothman" <amichai2@amichais.net>
Date: Tue, 25 May 2021 23:00:48 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
In-Reply-To: <CAP=vD9sq72MKuw37voGE-0FAHpDXS-QsaRDHK04d3jFuNunyHA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------0DCCCC539C1270E44619F497"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/OljdxzjDavMNqic04PscKXc3TYE>
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: Tue, 25 May 2021 20:00:57 -0000

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 
> <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 
> <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 
> <mailto: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 <mailto:OAuth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/oauth
>     <https://www.ietf.org/mailman/listinfo/oauth>
>