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

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

On 5/25/21 6:25 PM, Torsten Lodderstedt wrote:
> Hi,
>
>> Am 25.05.2021 um 16:59 schrieb A. Rothman <[e-mail]>:
>>
>> 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?
> yep.
Good, so I pass the sanity check :-)
>
>> 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.
Important to know.
>
>> 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.

"Trust but verify"... I'd like to understand this flow and its 
consequences, which is why I'm asking the pros on this list. It may be 
all good, but it smells funny, and is different from all others I've 
seen, so I'd like to be sure. The provider is not specifically a 
security service... just a resource server (in the RFC's terms) that to 
the best of my knowledge added an off-the-shelf OAUTH2 server from a 
well known vendor, but decided to only allow access to it (including the 
Authorization Endpoint) with MTLS. Which in turn forces our hand (as a 
client web server) to send the request from our server in place of the 
user agent, and pass back the URL from the Location header we receive in 
the returned redirect response back down to the user agent. We're not 
supposed to follow the redirect ourselves but just pass it down to the 
user agent (which in itself feels a bit hackish, not sure if that's 
valid processing for an HTTP redirect response).

>
>> 4. If it is less secure, what are the possible vulnerabilities or attacks made possible here that are mitigated in the original flow?

Are there any new attacks that can occur in this setup? Since the 
Authorization Request and Authorization Response are not in the same TLS 
and HTTP session as in the 'normal' flow, but occur on two different 
machines/sessions? With a new kind of redirect in between? Or for any 
other reason, is this more vulnerable?

At the very least, is it correct to assume this requires separate 
research because it is not fully covered by the analysis of the standard 
OAUTH2 protocol? i.e. the security of such a flow should be considered 
'unknown' rather than 'as secure as the normal flow'? Or can I assume it 
is just as secure?

>>
>> 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).
Is this just an optimization or an actual security weakness in the 
standard OAUTH2 flow?
>
> Fo this and other reasons, the OAuth WG has specified the Pushed Authorization Requests (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par) extension that works similarly. We indeed have done a security analysis of this draft.
I haven't heard of this before, but what they're doing does not sound 
like this, I think (I haven't read it fully, but watched the video from 
the other response to this thread). There's no separate par endpoint, no 
JSON response, and the user agent is not redirected to make the 
Authorization Request with par-specific params, to the best of my 
knowledge. It's more like just the regular OAUTH2 flow, just started off 
with a request sent from the client instead of from the user agent.
>
> BTW: the communication between user agent and authorisation server is still not protected with mTLS in the solution you described ;-).

Exactly. I'm still unsure what problem the mTLS here is trying to solve, 
if any :-)

If it can be shown that there is a problem with this flow, or at least 
unknown security consequences, perhaps I can convince them to remove 
this requirement and just do normal OAUTH2.

>
> best regards,
> Torsten.
>
>> Thanks,
>>
>> Amichai
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1622559602000000&usg=AOvVaw3uYa4JD_Cmmp4TyaTR0UqL