On 5/25/21 6:25 PM, Torsten Lodderstedt wrote:
Hi,
Am 25.05.2021 um 16:59 schrieb A. Rothman <amich...@amichais.net>:
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
OAuth@ietf.org
https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1622559602000000&usg=AOvVaw3uYa4JD_Cmmp4TyaTR0UqL
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
