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

["A. Rothman" <[e-mail]>]

Justin,

Thanks for this analysis. It pretty much sums up my own thoughts about 
this better than I could have :-)

I just hope I wasn't 'leading the witness' too much... I'll have to 
double-check the details to make sure I didn't miss anything, but as I 
understand it, that's more or less it.

btw it occurred to me that PAR wouldn't solve this specific problem 
either - if I understood correctly, it still ends with the user agent 
sending an Authorization Request to the AS, just with PAR-specific 
parameters instead of the usual ones... if so, and if the endpoint is 
still required to use mTLS, thus needs to be sent by the client... it 
would just be kicking the can down the road and violating the PAR spec 
instead.

Thanks again for your time and explanations,

Amichai

On 5/26/21 1:21 AM, Justin Richer wrote:
> It’s different, and I think in this specific case it’s more likely to 
> be less secure because of a lot of other red flags that I’m seeing 
> around this description.
>
> One, requiring MTLS on all endpoints without thinking through what 
> that actually means for developers. This is going to force developers 
> to come up with weird workarounds that you don’t anticipate instead of 
> building things into the protocol with good expectations and 
> boundaries. I can only guess to motivations, but it feels strongly 
> like “TLS is good, MTLS must be better” style security architecture 
> decisions, which are almost always wrong.
>
> Two, they’re asking you to break HTTP norms by reading a Location 
> header and passing it to another party instead of following it as the 
> HTTP spec says to do. Assuming that this location header points to 
> something that isn’t protected by MTLS, you have to wonder why they 
> want to put MTLS over the authorization endpoint in the first place if 
> you’re chucking someone over to a non-MTLS endpoint after that. It’s a 
> weird decision.
>
> Three, there is not a flaw in OAuth that MTLS on this endpoint would 
> fix. There are plenty of known downsides and holes in the 
> authorization endpoint, thus the invention of PAR and GNAP as 
> mentioned earlier in the thread, but neither of these require MTLS and 
> both make use of a specific message on an endpoint that’s not the 
> authorization endpoint.
>
> Ultimately, it’s the attitude that bothers me more than the specifics 
> here. It might be “secure” in its design, but it’s asking people to do 
> something different from what’s specified elsewhere and it hasn’t 
> received any scrutiny from a wide community like the PAR and GNAP 
> specs have (and continue to have, as neither is fully final yet). 
> They’re doing things off-book to workaround problems that they’ve 
> created by trying to be “more secure”, the end result of which is more 
> than likely going to make things less secure overall.
>
>  — Justin
>
>> On May 25, 2021, at 4:21 PM, A. Rothman <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> Justin,
>>
>> Thanks for the clear answer. The distinction you make is indeed 
>> exactly the point I was asking about.
>>
>> So I got the first answer, which is that it is not compliant.
>>
>> Now the follow-up question is whether it is known to be any more or 
>> less secure than the normal flow, or simply unknown until further 
>> analysis is done, or dependent on their specific implementation in 
>> some way - although afaik they use an off-the-shelf standard OAUTH2 
>> server, just expect it to be accessed from the client instead of from 
>> the user agent, due to their added mTLS requirement on the entire 
>> server (including the Authorization endpoint).
>>
>> I'm still not sure what the motive is behind the mTLS requirement, 
>> though it's possible it just sounded like a good idea at the time to 
>> make it 'more secure', without realizing there are consequences (like 
>> being non-compliant with OAUTH2 and/or opening new potential attack 
>> vectors, if that's also the case - still trying to figure that one 
>> out). Is there any flaw in OAUTH2 that would require such mTLS on 
>> this endpoint? Is it worth the risks involved in deviating from the 
>> normal flow?
>>
>> Thanks,
>>
>> Amichai
>>
>> On 5/25/21 10:54 PM, Justin Richer wrote:
>>> One point, the client doesn’t POST to the authorization endpoint, 
>>> the resource owner’s browser is supposed to POST to the 
>>> authorization endpoint — it’s an important distinction. And in the 
>>> wild, this is really rare to see in use.
>>>
>>> As written, this is not compliant with OAuth2. I agree that this 
>>> sounds a lot like PAR, except for the fact that the URL getting sent 
>>> back sounds like it’s used directly as the redirect. Where PAR sends 
>>> back a URI to be tacked onto the authorization endpoint as a 
>>> parameter, this is sending back the full URL to send the browser to. 
>>> In this way, it sounds more like GNAP’s “redirect” interaction start 
>>> method, which follows that pattern.
>>>
>>> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-05.html#name-redirect-to-an-arbitrary-ur 
>>> <https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-05.html#name-redirect-to-an-arbitrary-ur>
>>>
>>> GNAP uses this pattern for both greater security and greater 
>>> flexibility in this step — In my opinion it’s basically what PAR 
>>> would have been if we hadn’t started with the parameterized 
>>> authorization endpoint.
>>>
>>>  — Justin
>>>
>>>> On May 25, 2021, at 11:28 AM, Sascha Preibisch 
>>>> <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] 
>>>> <mailto:[e-mail]>> 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
>>>>     [e-mail] <mailto:[e-mail]>
>>>>     https://www.ietf.org/mailman/listinfo/oauth
>>>>     <https://www.ietf.org/mailman/listinfo/oauth>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>