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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to