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