Being able to redirect with 307 when session timeout and token refreshes about gloo

[DuncanDoyle]

Note that the HTTP/1.1 specification states that (https://www.rfc-editor.org/rfc/rfc2616#section-10.3.3):

RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.

So it seems that 307 is simply an addition to the spec because every browser/user-agent is not correctly processing 302 (i.e. they change the HTTP method to GET). So 307 is processed how 302 "should" be processed, redirect but don't change the HTTP method.

[DuncanDoyle]

@edubonifs I assume this is with OAuth Authorization Code Flow, right?

[edubonifs]

Yes @DuncanDoyle , OAuth Authorization Code Flow

[DuncanDoyle]

Reproducer: https://github.com/DuncanDoyle/ge-gloo-9231

AFAICT, the redirect we do in the "dance" with the IdP (Keycloak in the reproducer) store the endpoint to redirect to in the state JWT. We don't store which HTTP method was originally used for the request. Another potential problem is that, even if we would be able to redirect with the correct method (e.g. a POST in this example), also the original data that was send on the POST request needs to be stored in the state JWT. And this could probably introduce a number of issues:

• We could send sensitive data to the IdP as part of that state.
• The state is sent as a query param, and therefore has limited size. The HTTP POST data can potentially be very large, resulting in a very large query param.
• The state query param could contain sensitive data that could be logged in access logs if not careful.

Tbh, I don't know what the OAuth specification states about this scenario. I'm not sure if it can be supported and how ....