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