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
<saschapreibi...@gmail.com <mailto:saschapreibi...@gmail.com>> 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 <amich...@amichais.net
<mailto:amich...@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>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
