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

From: "A. Rothman" <[email-masked]>
Date: Tue, 25 May 2021 17:59:47 +0300

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 25 May 2021 17:25:20 +0200

Hi,

> Am 25.05.2021 um 16:59 schrieb A. Rothman <[email-masked]>:
> 
> Hi,
> 
> 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).
> 

yep. 

> 
> 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:
> 

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 (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par) 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,
Torsten.  

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

---

From: Sascha Preibisch <[email-masked]>
Date: Tue, 25 May 2021 08:28:56 -0700

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. 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

- 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 <[email-masked]> wrote:

> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: "A. Rothman" <[email-masked]>
Date: Tue, 25 May 2021 22:50:08 +0300

>> 1. Basically correct so far?
Good, so I pass the sanity check :-)
>> 2. Is this compliant with the RFC?
Important to know.
> 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?

> 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. W…
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 d…
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.

---

From: Justin Richer <[email-masked]>
Date: Tue, 25 May 2021 15:54:42 -0400

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: "A. Rothman" <[email-masked]>
Date: Tue, 25 May 2021 23:00:48 +0300

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

---

From: "A. Rothman" <[email-masked]>
Date: Tue, 25 May 2021 23:21:18 +0300

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 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hello Amichai!
>>
>> - This RFC suggests sending a request to the authorization server, 
>> get a session specific URL back which can be forwarded to the 
>> seeing on your web server: 
>> https://www.youtube.com/watch?v=fE11HJRCL-k

---

From: Justin Richer <[email-masked]>
Date: Tue, 25 May 2021 18:21:23 -0400

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 <[email-masked]> wrote:
> 
> Justin,
> 
> Thanks for the clear answer. The distinction you make is indeed exactly the point I was asking about.
> 
> 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 May 25, 2021, at 11:28 AM, Sascha Preibisch <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hello Amichai!
>>>

---

From: "A. Rothman" <[email-masked]>
Date: Wed, 26 May 2021 02:03:02 +0300

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 <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Justin,
>>
>> 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).
>>
>> 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
>>
>>> 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.
>>>
>>> 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
>>>
>>>> <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:

---

From: Justin Richer <[email-masked]>
Date: Tue, 25 May 2021 23:37:35 +0000

I'm actually wondering if we should add discussion about not putting mtls on the authorisation endpoint into OAuth 2.1. Aaron et al, thoughts? 

-Justin
________________________________________
From: A. Rothman [[email-masked]]
Sent: Tuesday, May 25, 2021 7:03 PM
To: Justin Richer
Cc: Sascha Preibisch; IETF oauth WG
Subject: Re: [OAUTH-WG] Can a client send the Authorization Request?

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.

Amichai

 — Justin

On May 25, 2021, at 4:21 PM, A. Rothman <[email-masked]<mailto:[email-masked]>> wrote:

Justin,

Thanks,

Amichai

 — Justin

On May 25, 2021, at 11:28 AM, Sascha Preibisch <[email-masked]<mailto:[email-masked]>> wrote:

Hello Amichai!

- 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. 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

I hope this helps,
Sascha

On Tue, 25 May 2021 at 08:00, A. Rothman <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

So the questions are:

Thanks,

Amichai

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Aaron Parecki <[email-masked]>
Date: Tue, 25 May 2021 16:43:14 -0700

Honestly it didn't even occur to me that someone would try this, since the
entire point of the authorization endpoint is that it's the thing the
user's browser talks to. Adding MTLS just means you're going to have to
send the user to some other endpoint instead, which is then effectively
acting as the authorization endpoint anyway. So yeah I could see adding
some language around the authorization endpoint needing to be accessible by
the user agent without MTLS or other funny stuff.

PAR also fits in nicely in that case since the PAR endpoint could be
protected with MTLS since it *is* intended to only be accessible from the
OAuth client.

Aaron

On Tue, May 25, 2021 at 4:38 PM Justin Richer <[email-masked]> wrote:

> I'm actually wondering if we should add discussion about not putting mtls
> on the authorisation endpoint into OAuth 2.1. Aaron et al, thoughts?
>
> -Justin
> 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.
>

---

From: Sascha Preibisch <[email-masked]>
Date: Tue, 25 May 2021 18:15:35 -0700

Amichai,

I know POST won't be seen often, but the /authorize endpoint may still
accept POST as described here:
https://tools.ietf.org/html/rfc6749#section-3.1

I hope this helps,
Sascha

On Tue., May 25, 2021, 13:00 A. Rothman, <[email-masked]> wrote:

> 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

---

From: "A. Rothman" <[email-masked]>
Date: Wed, 26 May 2021 08:17:33 +0300

Oh, I see what you mean... however as Justin clarified, the discussion 
here is not about GET vs POST, but rather about user agent vs client 
making the request. The former distinction doesn't really matter in this 
case, whereas in the latter distinction the client option seems to be 
breaking the spec (only the user agent should send it).

Amichai

On 5/26/21 4:15 AM, Sascha Preibisch wrote:
> <https://tools.ietf.org/html/rfc6749#section-3.1>
>
> I hope this helps,
> Sascha
>
>
> On Tue., May 25, 2021, 13:00 A. Rothman, <[email-masked] 
>     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
>
>>     - 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):

---

From: Sascha Preibisch <[email-masked]>
Date: Tue, 25 May 2021 22:38:50 -0700

Yes, I understand. I just wanted to clarify how I came up with ssying POST
is an option.
Regards,
Sascha

On Tue., May 25, 2021, 22:17 A. Rothman, <[email-masked]> wrote:

> here is not about GET vs POST, but rather about user agent vs client making
> the request. The former distinction doesn't really matter in this case,
> whereas in the latter distinction the client option seems to be breaking
> the spec (only the user agent should send it).
>
> Amichai
>> initial request coming out of the client instead of the user agent, without
>> any of the specifics of the par mentioned in the video.
>>

---

From: "A. Rothman" <[email-masked]>
Date: Thu, 27 May 2021 10:13:21 +0300

Maybe also worth mentioning something in RFC 8705, being the "OAuth 
MTLS" spec, along with the main OAuth 2.1 spec... I don't know how 
you'll arrange the RFCs next time around :-)

On 5/26/21 2:43 AM, Aaron Parecki wrote:
> Honestly it didn't even occur to me that someone would try this, since 
> the entire point of the authorization endpoint is that it's the thing 
> the user's browser talks to. Adding MTLS just means you're going to 
> have to send the user to some other endpoint instead, which is then 
> effectively acting as the authorization endpoint anyway. So yeah I 
> could see adding some language around the authorization endpoint 
> needing to be accessible by the user agent without MTLS or other funny 
> stuff.
>
> protected with MTLS since it *is* intended to only be accessible from 
> the OAuth client.
>
> Aaron
>
> On Tue, May 25, 2021 at 4:38 PM Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I'm actually wondering if we should add discussion about not
>     putting mtls on the authorisation endpoint into OAuth 2.1. Aaron
>     et al, thoughts?
>
>     -Justin
>     From: A. Rothman [[email-masked]
>     <mailto:[email-masked]>]
>     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.
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 28 May 2021 14:21:18 -0400

So the text of RFC8705 is fixed, it could eventually be updated and obsoleted by another RFC, but that would take a new effort from the WG to consider it worthwhile. Not likely to happen for an implementation note like this, unfortunately. But OAuth 2.1 is meant to account for all of the different extensions and profiles of OAuth that are already out there, so it’s a really good place to discuss that kind of thing.

 — Justin

> On May 27, 2021, at 3:13 AM, A. Rothman <[email-masked]> wrote:
> 
> Maybe also worth mentioning something in RFC 8705, being the "OAuth MTLS" spec, along with the main OAuth 2.1 spec... I don't know how you'll arrange the RFCs next time around :-)
> 
>> Honestly it didn't even occur to me that someone would try this, since the entire point of the authorization endpoint is that it's the thing the user's browser talks to. Adding MTLS just means you're going to have to send the user to some other endpoint instead, which is then effectively acting as the authorization endpoint anyway. So yeah I could see adding some language around the authorization endpoint needing to be accessible by the user agent without MTLS or other funny stuff.
>> 
>> PAR also fits in nicely in that case since the PAR endpoint could be protected with MTLS since it *is* intended to only be accessible from the OAuth client.
>> 
>> Aaron
>> 
>> On Tue, May 25, 2021 at 4:38 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> From: A. Rothman [[email-masked] <mailto:[email-masked]>]

---

From: "A. Rothman" <[email-masked]>
Date: Sat, 29 May 2021 11:32:21 +0300

Yeah, I just meant it could naturally fit also in the next iteration of 
RFC8705, if/when it is superseded. In the main spec would obviously be 
great :-)

Thanks!

Amichai

On 5/28/21 9:21 PM, Justin Richer wrote:
> So the text of RFC8705 is fixed, it could eventually be updated and 
> obsoleted by another RFC, but that would take a new effort from the WG 
> to consider it worthwhile. Not likely to happen for an implementation 
> note like this, unfortunately. But OAuth 2.1 is meant to account for 
> all of the different extensions and profiles of OAuth that are already 
> out there, so it’s a really good place to discuss that kind of thing.
>
>  — Justin
>
>> On May 27, 2021, at 3:13 AM, A. Rothman <[email-masked] 
>>> Honestly it didn't even occur to me that someone would try this, 
>>> since the entire point of the authorization endpoint is that it's 
>>> the thing the user's browser talks to. Adding MTLS just means you're 
>>> going to have to send the user to some other endpoint instead, which 
>>> is then effectively acting as the authorization endpoint anyway. So 
>>> yeah I could see adding some language around the 
>>> authorization endpoint needing to be accessible by the user agent 
>>> without MTLS or other funny stuff.
>>>
>>> protected with MTLS since it *is* intended to only be accessible 
>>> from the OAuth client.
>>>
>>> Aaron
>>>
>>>     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.
>>>