Yes, I understand. I just wanted to clarify how I came up with ssying POST is an option. Regards, Sascha
On Tue., May 25, 2021, 22:17 A. Rothman, <amich...@amichais.net> wrote: > Oh, I see what you mean... however as Justin clarified, the discussion > here is not about GET vs POST, but rather about user agent vs client making > the request. The former distinction doesn't really matter in this case, > whereas in the latter distinction the client option seems to be breaking > the spec (only the user agent should send it). > > Amichai > On 5/26/21 4:15 AM, Sascha Preibisch wrote: > > 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
