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