Backends-for-frontend's feature broken when accessing application directly in a browser (not using launch button)

[hrdflt]

Expected behavior

When using the backends-for-frontend's feature, teleport should first redirect the user to any backend application dependencies defined in the required_apps spec of a frontend application resource to populate the browser with the necessary cookies before redirecting the user to the frontend application.

With cookies populated in the browser for both the backend and frontend application, any backend API calls made by the frontend are authenticated with teleport, thus avoiding a 302 which will confuse frontend code.

Current behavior

teleport only redirects the user to application resource dependencies as defined by required_apps and populates the browser with cookies for that backend dependency when using the launch button from the teleport ui, and neglects to do this when accessing the application directly (from say a bookmark, or by entering it directly into your browser bar).

Details

In the browser developer tools / network area I observed that when you access the domain / URL for a frontend application directly (not using the launch button such as by clicking a bookmark or going to the URL directly in your browser bar) the first 302 redirect in the GET response to the /x-teleport-auth URI neglects to contain a Location header with the correct GET parameters (ie. required-apps=my-backend-app. The request flow differs from that observed when you use the launch button (where the GET parameters are seemingly correctly included which redirect you to any required_apps dependencies FIRST)

This results in a lack of necessary cookies being added to the browser for the backend domain (which would have been used by the frontend, assuming the frontend makes requests using credentials: include in the fetch, and the correct CORS headers are configured)

❗ In the observation below admin is my frontend application and api-admin is my backend application. api-admin is listed in the required_apps field of the frontend admin. The teleport domain is teleport.mydomain.com, and the subdomains admin.teleport.mydomain.com and api-admin.teleport.mydomain.com are used.

Observed Behavior of first 302 response in request flow

✅ Launch Button for "admin" app

• Request: GET http://teleport.mydomain.com/x-teleport-auth
• Response: Location: https://teleport.mydomain.com/web/launch/api-admin.teleport.mydomain.com/teleport.mydomain.com/api-admin.teleport.mydomain.com?path=&required-apps=api-admin.teleport.mydomain.com%2Cadmin.teleport.mydomain.com

❌ Direct URL access for "admin" app

• Direct URL: https://admin.teleport.mydomain.com
• Request: GET http://teleport.mydomain.com/x-teleport-auth?path=%2F
• Response: Location: https://teleport.mydomain.com/web/launch/admin.teleport.mydomain.com?path=%2F&required-apps=&state=33c84502f6f70848f42339982785ac62_122671e0a82d4e9627a5a99a17105480

Missing required-apps GET parameter value. URI scheme is different than when using the launch button altogether

Bug details

• Teleport version: 17.1.4

Reproduction Steps

1. Define a frontend and backend application in your teleport app resources
2. Add a required_apps dependency for the backend application in the frontend
3. Clear all cookies and cache in your browser
4. Open developer tools + network tab in your browser
5. Access the application directly in your browser by entering it into your address bar in the format of app-name.teleport-domain.com
6. Observe the first 302 response in the request flow for GET /x-teleport-auth: The Location header in the response neglects to contain the correct required_apps GET parameter. The browser will not go through the cookie population process for the backend application and go directly to the frontend application. If your frontend code makes a request to the backend, you will get another 302 (in an attempt to get the cookie/session) rather than being piped directly to the backend application (the request is seen as unauthenticated from teleport's perspective)