Use HTTP 303 for redirects, instead HTTP 307

[abstractj]

The option InvalidAuthRedirectsWith303 was removed, as does not make
sense to have it anymore.

More details:
https://tools.ietf.org/id/draft-ietf-oauth-security-topics-08.html#rfc.section.3.9

Resolves #627

[ackerleytng]

Thanks @abstractj !

Didn't know about the RFC you quoted!

Strictly speaking, I think section 3.9 refers to the redirect from the authorization server back to the client (whose role louketo takes, in this case), so it's slightly different from the changes in the code in this PR, which is about redirects from the client to the authorization server in the earlier phase of the auth code flow prior to authentication with the authorization server.

I think the concerns still apply, though - we shouldn't be leaking information posted to the client to the authorization server either.

Also, I was confused by the header of this PR, I think you meant "Use HTTP 303 for redirects, instead of HTTP 307".

Thanks for your work on louketo! It's an awesomely useful proxy.

[abstractj]

Hi @ackerleytng thanks for reviewing it. Indeed the title was incorrect and should be fixed now. Reading your last comments, what exactly is still being leaked now that we are using HTTP 303?

[stianst]

LGTM, but would probably be good to get someone with more knowledge on Go and the code base to review as well

[ackerleytng]

Thanks again @abstractj ! I think there's some misunderstanding there. I meant that the concerns expressed in the RFC are for redirection from authorisation server back to client, but the same concerns apply for us, even though we're redirecting from client to authorization server.

Using a 303 should address those concerns! Thanks for making this change.