Long redirect URLs cause tsh login to fail

[russjones]

Problem

Use reported seeing the following errors when attempting to use tsh login with their SSO provider. Web UI login works fine.

ERRO [WEB]       Error while processing callback. auth:oidc error:[
ERROR REPORT:
Original Error: *trace.RawTrace invalid_grant: Invalid or expired code parameter.

This error was coming from their identity provider because the code token has already been consumed.

Upon investigation, it was discovered that the entire SSO login flow is successful until the 302 console redirect to transfer credentials from the browser to disk. This was due to the user running a middleware component that intercepts all requests and drop requests with headers larger than 8 kb and Teleport was sending a Location header that was 16 kb.

The middleware would accept the request, drop it, then the 302 console redirect would be tried again and this time fail at the IdP (hence the error above) but succeed because the header was now smaller than 8 kb.

User reports that this is not the middleware they are running, but other popular Cloud services, like AWS ALB, also enforce 8 kb limits on headers.

Proposed Solution

This process starts with the IdP issuing a POST /webapi/saml/acs request which eventually becomes the 302 console redirect. Instead of performing a 302 console redirect, Teleport could return a small Javascript application that uses window.location to perform the redirect. We use a similar approach in Application Access.

https://github.com/gravitational/teleport/blob/master/lib/web/app/redirect.go

This would solve the problem because this request would not be caught by any middleware and instead happen local to the users workstation only.

[jsonmorris]

This also applies to oidc login redirects in addition to saml redirects.

[russjones]

@codingllama Let's sync about this on Thursday, talked with @klizhentas, there is another way to solve this problem that works well with the future work on Teleport Terminal.

[codingllama]

Relevant: #7493.

[russjones]

Assigned to @atburke the window.location approach which will act as a stopgap solution until we can implement #7493.

[atburke]

I've tested the SSO workflow, and although most of it works without javascript, the final success/error pages don't. I think it's safe to assume that users won't have javascript disabled and that the window.location approach shouldn't break any existing workflows (and if not, we could try HTML Redirects).

As for implementation, I think the simplest approach would be to add a new version of Handler.WithRedirect that serves the javascript app instead of returning 302.

[russjones]

@alex-kovoy What do you think above the above? I can provide you more details tomorrow if you'd like.